MarkItUp

Have you downloaded VS2008 and started using it to create .NET 3.5 solutions?  Pretty cool huh... inbuilt support for ASP.NET Ajax projects and all the goodness that we get from Linq too.  What about your development environment?  Are you using TFS to manage your source control and build processes?  If you answered "yes" to both of those questions then I'll bet that, like me, you've been horrified to learn that you cannot build Visual Studio 2008 and .NET 3.5 projects natively with your existing TFS 2005 environment. 

Thankfully, over on the TFSNow blog, Mitch has just posted the following article which comes to the rescue:

Building .NET 3.5 Applications with Team Build 2005 « TFS Now

I'm so grateful to Mitch for spelunking his way around to find these solutions for us.  Over the past 2 weeks, as we've started developing VS2008 solutions which target the .NET 3.5 runtime, it's been very frustrating not having CI and all the goodness that comes with doing automated builds.  Now thanks to Mitch we can forge ahead using .NET 3.5 with all its Linq'y goodness while still being able to keep our automated build and deployment processes in place.  That's what I call having your cake and eating it too!

Greg's book has hit the virtual shelves: 

Book: The Rational Guide To Building Technical Communities - The Bit Bucket

I had the good fortune of reading this for Greg while he was writing it and I have to say that it's an invaluable guide to technical communities.  I loved the approach that Greg took by writing shorter chapters that are packed full of good advice and pragmatism.  Every chapter taught me something that was valuable and I found that I didn't have to wade through the endless crap that you get with the standard 30 page per chapter approach that tends to be the norm.

Highly recommended.

Last night I rang Mitch and I was very , I actually thought that I was going to  there was no joy in the world and things were basically .  Tonight, because of this post, I am  again... no, make that  and .  Mitch, you are . 

Let me say it... Mitch, when it comes to TFS and .NET, you are , and if you were here right now I'd give you a great big . 

You don't scale.  Get it?  No matter what you do, there will only ever be one of you and you are therefore limited in what you can achieve. 

Presuming that you have limits to both the physical speed at which you can execute tasks from your "stack" and that you also require meals and sleep, then you don't really have much available time to do stuff, do you.  Maybe less than 15 hours per day... not much at all really.

If you are smart then you might realize that this means there is a limit to the number of things that you can do - which means that you don't scale. 

The only way to scale is to learn how to manage other people - which means learning how to communicate with them and delegate to them.

You don't scale.

Grant offered up his Tech.Ed schedule here so I thought I'd blog mine too...

Greg has announced the Readify Developer Network (RDN): 

Announcing the Readify Developer Network - The Bit Bucket

I'm so glad to see the RDN reach this stage of its life and think that it will be a great addition to both Readify, as well as the broader developer community.  From memory I have a talk about managing the development process, but there are heaps of great talks from people such as Damo (Silverlight), Greg (SQL Server 2008), Paul Stovell (Domain Modelling), Bill Chesnut (BizTalk + WCF) and Richard Banks (Agile, Team Development), to name just a few.

Please read Greg's post at the above link to learn all about RDN and follow the link to RDN on our website to learn about the 2-tiers of presentations that we have: ReadiDepth and ReadiPrimer.

Woot!

As Frank blogged yesterday, there will be a blogger's lunch on Wednesday at Tech.Ed next week to discuss Web 2.0 and Social Networking.  I'm on the panel with 4 others:

Panelists

• Jane O'Connell, Product and Network Strategy, ninemsn.
• Phil Sim, Founder, MediaConnect
• Darren Neimke, (Me) 
• Michael Platt, Director, Web Application Architecture, Microsoft US
• Frank Arrigo, Technical Community Manager Microsoft Australia

What a great opportunity to discuss Web 2.0 and ponder what it means for traditional media.  If you'd like to take part in this discussion then Frank has also blogged what you need to do to register for the event here.

What do you think?  Is Web 2.0 worth all the hype?  In what area of your life does "Web 2.0" have the biggest impact?

Happy SysAdmin day Grant. 

July 27th, 2007 (Last Friday Of July)
8th Annual
System Administrator Appreciation Day

System Administrator Appreciation Day

I've mentioned a few times before that we use SharedView in the Dev Centre to do remote pair programming.  It's quite an awesome experience and, even as I type this message, I'm watching Paul Stovell typing code from the screen on my other laptop.  In the following image I'm working from Adelaide in the screen on the left while Paul is coding in Sydney in the machine on the right:

One of the things that is cumbersome at the moment is communication with each other when you are pairing.  I've tended to use the phone and hook my earphones up and have a phone-connected session while we are pairing but, invariably, the other person has tended not to have earphones for their phone.  So they either end up holding their phone to their ear (bad) or we just use IM to chat while we are working.  Phone is best because you can have a high bandwidth experience whereas with IM you only chat a few times an hour.

The biggest issue with using IM to chat is that you are constantly switching context between the app that you are using and the IM client app.  So if I send Paul an IM message, he will have to switch away from VS and into his IM client app to view and respond to my message.  It's not so bad for Paul (who is controlling the sharing session in this case) because he just tends to type me messages directly within the IDE when he has something quick to say.  So the problem is really with the non-controlling member having to use IM.

What I'd like to see is the ability to send Flash Messages that show up in the title bar or some other dedicated area within the Shared View client area that would display messages that I send to Paul.  That way I could be sending him messages and he could read them without having his workflow affected.

Jason writes some kind words about my Code Camp SA presentation and then asks whether I can recommend any good coffee shops in Adelaide that have internet availability:

Code Assassin - Code Camp SA: Darren Neimke

Sorry Jason, but I can't really recommend any decent coffee shops in Adelaide based on either their Wi-Fi or their access to electricity   We should create a Wiki to track that information. I have a Vodaphone Mobile Connect USB card so internet access seldom bothers me - just access to power. For power I've been working from the lobby at the Hyatt when I'm in town. For coffee I often work from the new Santos building because they have great, comfy chairs.

The main shops that I'm working from in Adelaide at the moment are:

1. Gloria Jean's Coffee Shop, Westfield Marion
   I'll have to check what paid wireless internet options you have access to from there.  They make a mean Hazelnut Latte.  No power options.
2. Santos Building, City
   This isn't the old Santos building in Currie Street but the new, "green" building in Flinders Street.  They've got awesome designer chairs that are really comfy to sit in and well-priced, large coffee.  No power options, not sure about wireless availability.
3. The Asian restaurant on the ground floor at the Grand, Glenelg
   During the day this is really quiet.  You have access to power and drinks.  For lunch, you can't go past either the Laksa or the Green Chicken Curry
4. The Hyatt, City
   I don't go here that often but if I'm down that end of town or running out of power then I'll happily work from the foyer at the Hyatt.  Nice chairs, and a wide open atmosphere.

In addition to those fine places I should mention that I also got a new coffee machine for my birthday on the weekend, so happily I'm able to drink decent coffee from home nowadays too!

If you are working with TFS then I behoove you to install this great TFS add-in for Outlook:

Outlook 2007 TFS Addin

When installed this add-in surfaces as a little toolbar in Outlook and allows you to create work items directly from emails simply by clicking on a "New" button.  The workflow scenarios that this enables are very useful indeed.  Now I can shoot an email off to my customer with a question, get a detailed reply from them, and convert the whole conversation to a work item.  A great way to ensure that you don't miss any customer requests while helping keep your inbox empty at the same time!

Mitch and Greg have both posted their thoughts on CodeCamp SA so I thought that I'd better mention it too.  It was great to catch up and re-connect with several old Adelaide friends and also to spend time with colleagues again.  Greg's talk on DMV's in SQL Server 2005 that was very interesting.  There's a lot of functionality in there - particularly the new reporting features that come as a standard part of SQL Server - that I didn't know about.  Dave Gardiner has posted a more thorough analysis of Greg's talk here. 

On Saturday evening I went out for dinner with Mitch, Dave Glover, and Jey Srikantha (from K2) and we had some great food and conversation.

It was also great that Mitch could stay over at our house and catch up with our family again - the kids were delighted to spend time with "Mitchy Mitch"   Mitch really helped me with getting my PowerPoint deck sorted out too!

My talk was a new topic that I'm working on and it was good to present it for the first time.  It's basically a "Tips and Tricks" session about managing a remote development process.  It was great to get it out there for the first time and I got some good feedback about the structure.  Below is my deck for anyone who was interested or who was unable to attend.  Next time I give this talk I'm going to change slides 15 and 16 from conversation-style slides and bust it out into maybe 6 more explicit "Tip and Trick" style slides.  It will vastly improve the structure and make the outcomes much more concrete.

	My opening slide
	It was originally advertised that I was going to talk about EntLib
	Nope
	Then it was advertised that I'd be talking about Enterprise 2.0
	Nup
	The topic of this talk
	Who I am - professionally * Consultant * Accounting/Finance background * My blog
	Who I am - personally * Coach of sporting teams * Book author * User Groups/Community * MVP, ASPInsider
	Who I work for * .NET Readiness Leaders * Tech.Ed's, Code Camps, User Groups, ReMIX, etc * Canberra, Adelaide, Sydney, Melbourne, Brisbane
	What I do * [Showed video of Cat Herding] * Herd cats  * Manage the Dev Centre
	What is the Dev Centre * Manage internal development * Some special characteristics
	1 - We are Remote * You cannot see your colleagues * Easy to go dark * You need strategies to work remotely
	2 - We are Mobile * Many tasks need to be done on devices * Need to make work processes more asynchronous
	Our processes * Our SCRUM implementation had to change * We have had good success at introducing the business to iterative development * Manage expectations of people coming to do work * IT rocks.  They work with us, not against us and are jointly a part of the delivery process.
	Our Tools * TFS - don't just use, make it work for you * TFS enhancements - TFSIntegrator, TFSDeployer, etc * Shared View - pair programming * Connected One Note sessions - our whiteboard
	How we Communicate * Wiki-based open communications policy * Good use of detailed check-in comments * Outcome-based scrums as opposed to task based * Message oriented communication
	Thanks for coming!

Quite often I'll hear Readify referred to as a virtual company.  The 'virtual' tag is applied to us by both internal as well as external observers - but what does it actually mean?  And is it an accurate tag to apply to us?

To me the term 'virtual' means "not real" or "almost real" - certainly not something that I equate with our company.   After all, it was only last week that I sat down for a meal with a bunch of our guys at Darling Harbor in Sydney.  Heck, it even set me back 70 bucks... what could be more real than that?  To me "virtual" is more of a SecondLife type of experience.  Actually I believe that as mechanisms such as Ideagoras and Crowdsourcing start to play a bigger part in how we share knowledge that will start to see true "virtual" organizations start to take shape - maybe virtual organizations that look nothing like organizations of today but which look more like virtual swarms that exist to solve important problems and then disassemble and vaporize just as soon as they formed.  But this is not anywhere near where we are at today.

I prefer to think of Readify from the viewpoint that we are highly distributed and decentralized.  In this sense we are more like a "remote" (although I prefer the term "distant") company.  Another, probably better term is that we are a highly mobile organization.  You see, to me, "mobility" means that we are able to work from anywhere.  This is closer to my real working model where I work from wherever I am at any given point in time.  The  slight (although significant) difference from "remote/distant" is that the latter implies that you are simply working offsite.  A minor differentiation but one which is important when you live and work how I do each day! 

Actually, according to this article, many more of us are at least migrating away from our ties to working from a central location.  If the statistics quoted in that article are correct, 14% of the US workforce currently works "from home" at least 2 days per week.  This is up from 11% in 2004 and is expected to rise to 17% within 2 years.  Certainly worth considering in terms of the opportunities that will arise from this new growth.

The trick with a mobile organization is having the right tools to enable key scenarios - such as collaboration as well as communication at a human level.  This article touches on some aspects of these key points.

At Readify we're experiencing all of these exciting new developments in our daily lives and it's an exciting place to be.  Moving forward I can see further evolution in the mobility model.  Increased mobility - and hence less dependence on location - will lead to us having:

1. Access to a wider recruitment audience
2. Greater collaboration with external parties
3. Access to more diverse pools of knowledge

A while ago I mentioned the new themes that have been added to Google Portal and I thought that I'd write a quick note to talk what one of my standard days looks like these days...

In the morning I love to get up early and have a coffee with Paul Stovell while I read the paper and check my emails...

In the Dev Centre there's plenty of time in the morning for goofing around.  Often Paul and I shoot water cannons at one another before we get stuck into our work...

... or practice a bit of karate...

... on other mornings it's nice to just kick back with a nice, gentleman-like game of badminton...

... the weather in Adelaide has been great so we tend to grab our sandwiches and head outside for lunch...  

In the afternoon's Paul's favorite activity is water-sliding... 

... but I much prefer a quiet game of croquet (Stovell never beats me at this )... 

... anyway, when the day is done it's time to start preparing for the night.  It's been a bit cold at night this winter so we generally prepare a bit of a fire...

... which, of course leads to marshmallows and Stovell's endless stories about his data binding feats! 

.... then it's time to Sleep... 

... and Dream - although I've been having some weird one's lately...

It's a busy life

Yesterday I wrote an article which questions whether or not the daily Scrum meetings stifle creativity.  Thankfully Richard added a comment which pointed me to an article by Martin Fowler about the Patterns of Daily Stand-up Meetings.  Having been on a couple of highly functional teams in the past I can relate to much of what Martin is saying but some of it was a revelation to me and, although it's a rather lengthy article, I'd highly recommend downloading it and reading it over a coffee in an appropriately quiet place.

Reading the article actually made me wonder about the suitability of Scrum daily meetings to the Dev Centre.  After all, the Scrum daily meetings are very much targeted at teams who are working on the same project whereas the Dev Centre is often a very different world.  For one, the teams in the Dev Centre tend to be highly disrupted; people tend to come and go all the time.  You might be working on a project in the Dev Centre today but in 2 weeks time you may not be there at all.  Another significant difference is that it's actually quite common to have either very small teams or, even more commonly, just an individual developer working alone.  How do you have a Scrum with just 1 regular developer?  It's a highly disruptive environment and not one that I'm certain is well addressed by the "manifesto" laid out in Martin's article - particularly when you lay "remote/virtual" over the top.

I actually wonder whether the model that I'm working with is more of the norm - let's call it the "long tail" - as opposed to the large to mid-sized teams that Martin's article (and the daily Scrum meeting itself) is targeted at?

Having said all that I do know one thing... I definitely want to tap into the goodness that teams get from Scrum meetings.  Shared ownership, better visibility, help with removing obstacles, team building.  However this would all exist within the scope of the members of the group as opposed to distinct project teams.

Maybe there is another process which is targeted at these highly disruptive groups but which is similar to Scrum?  Obviously I have more research ahead of me :-)

For the past few years nearly every project that I've been involved with has run a Scrum-like meeting.  I say Scrum-like rather than Scrum because none of these projects have had a certified Scrum-master... and I don't want to weaken my argument for the rest of this article on a mere technicality   Anyway, regardless of the Scrum'ness of the meetings, we do stick to those well known 3 questions that are associated with Scrum meetings:

1. What have you done since the last meeting?
2. What is impeding your work?
3. What do you plan to do between now and the next meeting?

The idea of the Scrum meeting is that you get in, ask your questions, and get out.  Very robotic and very focused.

In nearly all projects I've noticed a gradual decline in the level of interest that the team has for these meetings as time progresses and I think that it has something to do with the low level nature of the information that is exchanged during these meetings.  They've tended to be very task-oriented.  For example:

1. I'm going to put black borders on the buttons
2. Write the validation logic for the forms
3. Speak with the customer about how to do blah

It seems to me that the repetitive, constant, daily grind of reeling off facts breeds apathy for the process and before long these Scrum meetings become "yet another meeting".  When this happens I find that teams simply go through the motions and become less agile in their thinking about raising important issues or giving you information that could change and assist the process.  So how do you change it so that you get the goodness that the Scrum meeting is designed to deliver while getting good information from your team about how things are going and what needs to be done?

Up until this week I've been running daily SCRUM's in the Dev Centre but as of this morning I've decided to change it so that the weekly meetings will look more like this:

1. Monday morning creativity meeting.  Tell us your goals, dreams, and vision for what you are going to achieve this week.
2. Tuesday to Thursday. Either send a typical SCRUM meeting email or I'll call you on an ad-hoc basis to "kick the tyres".
3. Friday afternoon "beer-o-clock" session.  2 questions... Tell us what you achieved for the week and tell us what thing you would improve about the Dev Centre if you could improve any one thing at all.

Having meetings that are structured in this way will allow senior, responsible developers to become a little more self-managing and hopefully introduce enough creativity to produce a more creative culture.

Bottom line... take the blinkers off of your team.  The opportunity to gather should be a learning experience.  Use those precious moments together to learn from each other as to how you can improve... who knows, maybe you'll end up with a better culture because of it! 

The Dev Centre was created by Readify to manage the software development requirements of the business as well as to harvest IP from our existing processes.  Last week I started the process of setting the goals of the Dev Centre for the coming year.  One of the major goals for next year is to turn the Dev Centre into much more of a factory for creating software by standardizing on processes and increasing the levels of automation. 

Above all of the process and automation stuff, you also have to think about the things that are at the human level - such as creating an environment that people enjoy working in.  Happy, mentally-active people are productive people, and it's these people who will add the most to the culture of your business.  One of the things that comes up in this area on a fairly regular basis is pair-programming.  That is, people regularly ask for pair-programming to be implemented as a standard part of how we do things.

I always find this to be an interesting request because I've long been a fan of pair-programming and I can attest that my most significant programming victories have taken place through pair-programming sessions.  Within Readify I can immediately recount some major pair-programming victories with Francois Beaussier, Mitch, and Paul Stovell.  So the fact that there's no sign hanging above the (virtual) door of the Dev Centre certainly doesn't mean that I don't want to encourage it - I really do. 

Pair programming leads to the following highly desirable benefits:

1. Shared ownership of code.
2. Culture of mentoring.
3. Better designed code. 
4. Less bugs.

The challenges in implementing pair-programming are almost never technology or environment based but are more than likely people based. 

So if it's that difficult to get workers to pair-up in a standard office environment, what about when you have teams which operate within a virtual environment?  Virtual pair-programming requires not only the trigger for the developers to connect but also a set of tools that enable a rich collaboration to occur.  One of the tools that we've been playing with recently that might enable richer remote pair programming scenarios is Microsoft's new SharedView Beta.  This is a very exciting tool in how it provides collaborative experiences and I can easily see it becoming very often used within the Dev Centre at Readify.

One of the customs that we have in the Dev Centre at Readify is "the daily SCRUM".  This involves everyone who is working on a Dev Centre project to submit an email by 10AM with their answers to those 3 well-known questions.  Paul Stovell is a little different in that he tends to submit 2 SCRUM's - 1 which reflects the stuff that he does during his mild mannered daytime hours and another one which reflects the activities of his better known night-time alter ego SuperPaul.  Recently while Paul was working on one particular project he started spewing out colorful charts which reflected the level of testing that his code had achieved when measured against Requirements.  On those few evenings a couple of weeks ago was born "Scenario Coverage Analyser for TFS" and you can/should learn more about it by reading Paul's post on it here:

Scenario Coverage Analyser for TFS

Cool stuff!  We've now released this and you can grab it from our website at the following location:

http://readify.net/Default.aspx?tabid=269

Who knows, maybe soon your automated builds will be producing lovely charts such as this:

Here's a great quote found via this link: 

I start each project with two rules: all source files must be in a version control repository, and the build must be fully automated at all times.

This is another core requirement for all projects within the Dev Centre at Readify.  Having systems that ensure that your projects are always in a known state is the thing that will allow you to sleep peacefully at night... trust me on that!

The other day Mitch had some kind words to say about the Dev Centre at Readify and so I thought that I'd take the time to summarize the processes that we use.  First I'll start by stating the goals that I have for the Dev Centre:

The goal of the Dev Centre is to deliver usable software that helps our customers get their job done.

Sounds simple enough?   I believe that it's super important to keep things as simple as possible at all times.  So many times you see projects get bogged down in red tape and process.  By trimming away as much of the fat as possible you can hopefully avoid falling into the trap of spending too much time doing things that don't matter.

After stating the goal I can now elaborate on the actual process itself which is broken down into the following 4 parts:

1. Plan
   Duh!  All processes start with this   During this phase we spend a lot of time gathering scenarios so that we can distill the actual requirements.  The scenarios give us enough information to break out the tasks.
2. Design
   Technically speaking this is really part of the formal planning phase, but I like to separate it out on its own so that we can really focus on creating software that is usable - remember our goal   This phase will contain as much mocking-up and prototyping as is necessary for the customer to feel comfortable with the overall design.  Drawing things in OneNote doesn't take long but doing it will help your customer begin to visualize the end-user experience.
3. Create
   The emphasis here is on short, iterative cycles.  The more customer involvement and feedback that you can gather here will again assist with overall ownership at the end of the day.  Rule of thumb: 2 week iterations; at least weekly collaboration with customer.
4. Deploy
   Sit with the customer and take notes about any additional requirements.  Use this time to plan and prioritize future work.  The goal here is to get your customer to get their hands on the software and to have their say about things that could be better and hear about what they like.

That's it.  Overall, a very agile process where we get early feedback at each stage in the process.  Remaining close to the customer in the Create and Deploy stages allows us to gather real-time feedback and means that we can easily get the business to buy-off of adapting and refining what we are doing to constantly align to the needs of the customer.

OK, I've taken the plunge and created my SecondLife persona.  I don't know much about SecondLife etiquette yet so I'm not sure whether or not I'm supposed to blog my SecondLife name in real life - for that matter, should my second life persona have a blog?  Who knows?

Anyways, having worked in a virtual environment for some time now I can certainly see the benefits in a place like SecondLife where you can quickly go to catch up and meet your real world (and SecondLife) friends.

I'd actually like to see Readify have a SecondLife virtual apartment where we could meet up and go to to chill out.

I know that sounds a little wierd but unless you work for a virtual company you probably cannot fully appreciate the need to find virtual water coolers.  I imagine that having a SecondLife apartment that you'd bump into other Readifiarians quite regularly.  It could be a quick chat at breakfast or you might grab lunch together and chat about the day.  I think that there could even be a place for virtual SCRUMS to take place in an online location.

I'm going to play around with creating a few virtual meetings online and give it a try - but who knows, hopefully there could be a Readify meeting place in SecondLife soon

Ducas finally blogs  

Link to My World : A Blogging Endeavour...

'bout time Duke!

I'm sure that, you've architected applications and then managed teams as they've gone about implementing your designs to produce a final product.  As the architect you typically get involved in the process from the start and therefore have a good understanding of the requirements underlying the design.  In the case where you are a small team you've probably also designed and written quite a bit of the framework code and done most of the hard-core prototyping yourself. 

As your primary tasks come to an end, the development team tend to take over with development and then maintainance of the application.  At this point what is your ongoing role with the application?  Are you still charged with the responsibility of ensuring the performance and maintainability of the application?  If so, what is your strategy for having continued visibility over changes to the codebase and, ultimately the structural design of the applicaiton?  How do you maintain the quality assurance of your application?  Or do your applications all face a gradual decline in quality after their careful, initial design and creation?

Clearly you cannot keep an intimate knowledge over all of the applications in your stable because, as time increases, so does the number of applications that you've been involved with.  But what are the key indicators that you can leave in your wake to alert you about the general state of degradation over time?

During the week we had some information meetings for Readify staff in Melbourne and Sydney.  These events were a great way for us to all catch up with one another and, because we've had so much growth over the past 6 months, for some it was the first time that we'd met.  Unfortunately I was unable to attend the Melbourne event - due to family commitments.  The Sydney event was well attended with about 24 of us on deck to keep the beer and wine flowing and to talk about where we're headed as a company over the next 12 months.

Mark Landells, Phil Beadle, me, and Grant Holliday.

There were many things to discuss during the evening because we've grown both in terms of number of consultants but also we've nearly doubled the size of the management team.  Grant talked about our IT infrastructure and where we are at with our MOSS implementation as well as with Exchange 2007.  Andrew Parsons talked about Readify's upcoming involvement with ReMIX and also our plans for Tech.Ed attendance later this year.  I talked about what I've been up to with the Dev Centre and also explained how the PD program will be run next year.

Talking about the new Dev Centre and PD program.

All-in-all it was a terrific evening and it was great to catch up with all the guys again.  You can well imagine the amount of passion and the number of interesting conversations that ensue when you have people like Mitch Denny, Paul Glavich, Greg Low, and Paul Stovell (to name but a few) in a room together

Recently I started with my new role as manager of the Development Center at Readify.  You can read the announcement of this appointment on the Readify Media Release page (subscribe to the RSS feed while you're there )

It's a great role, and one that allows me use the latest technologies to put together solutions for the Readify business and beyond.  Technology aside, I stand by my quote in the media release announcement:

Whilst working with the latest technology always presents unique challenges, the greatest challenge that I see for Readify is having the right processes in place to continually deliver value to our customers...

It's one thing to know the tools and when to use them but you still need to have a proper plan which underpins the things that you do on a day-to-day basis.  Why is this so important?   Consider that you've been charged with managing a development process.  Without a solid plan where will you be after a year?  Sure you may deliver applications but I believe that a good development process should aim to deliver way beyond just the applications that we build.  A healthy development process can lead the way rather than lag behind the business.  A healthy development process is an incubator for professional development skills.  A healthy development process consistently delivers applications that meet the expectations of its customers.  A healthy development process has healthy communication.

A year is a long time in software development.  With 2 developers, every week is 80 hours.  Every month is 350 hours.  Each quarter is 1040 hours.  The year itself totals nearly 4200 hours and then you need to add your own 2100 hours on top of that.

Being given 6300 hours, 2 crack developers, the latest technology, and the needs of a growing organization is a wonderful opportunity and it's the reason I believe it to be so important to build something of significance.  At the end of the year you will look in the mirror and it's then that you'll know whether you've used all of those resources to build something of value or not.  What could be worse than wasting such a rich pool of opportunity!

Some of the best advice that I can offer to date is that prioritization is of the highest importance.  Pick the things that you believe will get you to where you want to be in a year from now, assign them a high priority, and set sail.

Dan is rapidly becoming our in-house Card Space guru and now he's added it to his blog.  You can try it out here: 

Link to dbartholomew.net > Home ( DNN 4.4.1 )

How long will it be before we can add this to our own website I wonder

We've done it again... first Juval visited our shores to deliver the WCF Master Class - the most in-depth class that we've seen on WCF to date.  Now we've secured Ian Griffiths to come and deliver the WPF sibling - Applied WPF:

Link to Applied WPF

Ian is co-author of the Programming WPF book which is considered to be one of the authoratative sources for programming real world WPF applications.  This 4 day course starts on the 23rd April so you'd better be quick if you would like to catch this one-off opportunity to learn from one of the real masters of this technology.

Book Now!

With the rise of WPF as the UI technology and the emergence of WPF/e as a very serious offering in the web space this is something that you simply cannot afford to miss.

Code Camp Oz is fast arriving and this year Readify are making available some special T-Shirts to mark the occassion, you can order your own CodeCampOz custom T via the following URL: 

Link to Code Camp Oz 2007

The cool part of this is that you can add your own custom message to the back of the T-Shirt!  So go order one and send a message at Code Camp this year 

See you all there... can't wait!

Recently I put together 3 Webcasts to show how to use the State Machine workflows in Windows Workflow.  You can view them here:

1. Introduction to State Machines
2. Architecting State Machines
3. Using Persistent Workflows

You can view all of the Readify Webcasts on .NET 3 technology via this landing page:

http://www.readify.com.au/tech+tutor.aspx

During the past month I think that we changed the mailing process for our External Newsletter so that it is now directly run off of our contacts in CRM. I think that in updating to that process I may have been omitted because I don't remember getting a copy.  Anyways, it went out and my article was the feature article for the month.  It was about Vista Sidebar Gadgets.  You can read it here:

Tech Talk

Oh yeah, don't forget to sign up to receive the newsletter!  I believe that the feature article for our next newsletter - due in a couple of weeks - was written by Chris Burrows and is on the topic of how to professionally manage the processes of building and releasing your SQL Code.

Readify colleague Grant lifted the lid on his new role the other day and I'm pleased to announce that soon I'll also have a new title: Development Center Manager.  At some time in the next month I'll hand the over the reigns to the HR part of my role to focus purely on internal IP and product development opportunities.

The first applications are already on the assembly line so hopefully, within the next couple of months our new Marketing Manager will be able to lift the lid on some shiny new Ajax and WPF front-ended, Windows Workflow driven, WCF communicating, Sidebar accessible products

Oh yeah, while I still wear the hat, I should put in a solid HR plug... we're still on the lookout for new Readifiarians - especially in Sydney and Canberra.  If you're interested in a role at Readify then please contact me via the Feedback form on this blog. 

Cheers!

As announced by Frank, Phil and the guys set the new AFL.com.au site loose today:

http://afl.com.au

It's been amazing watching the guys go to work on this and to get some insights about how it's been put together behind the scenes.  In addition to using DNN as the portal front-end, I can also reveal that a lot of the data orchestrations that occur behind the scenes make use of SSIS.

Other Readify guys who have contributed to the success of this project have been Sydney-based Dan Bartholomew and Adelaide-based Andrew Ball.

Phil has done a great job getting DNN over the line for both the NRL and AFL sites in the past year!

The first week of the WCF Master Class is running in Melbourne next week and everybody here at Readify is getting excited as the final touches get put on things.  There's been some good press about this course too lately, here's an interview with Juval that was published on Computerworld today:

Link to Computerworld - Microsoft Software Legend on .NET 3.0, WCF and the future of software development

You can read more about the content in the course here.  You can also book from that page but I'm pretty sure that we are now only taking bookings for the Sydney classes that take place the week after next.

I'm always looking for the link to this great resource:

Link to Scott Hanselman's Computer Zen - What Great .NET Developers Ought To Know (More .NET Interview Questions)

As of today I'm internalizing that resource as an official member of the Readify hiring process   Thanks Scott!

People often ask about life at Readify and it's always a tough question to answer   Paul does a pretty good job with his Readify Roundup today of showing that there is always something happening:

    http://www.paulstovell.net/Posts/Post.aspx?postId=f6f02ee5-9d87-40ee-ac99-cbf36929cd9e

Just a couple of things to point from Paul's post:

1. Corneliu is not a real vampire - he'll only suck out your secure strings
2. Yes it is fairly typical to get 40-60 posts on the tech list in an afternoon

All-in-all you could say that it's a pretty active place.  And as Paul mentioned in his previous post, the activity is certainly not limited to just technical stuff!

I remember seeing the following great picture on the Coding Horror blog:

That picture was related to an article titled: Meet the Arch-Nemesis of Productivity: The Internet.

Related to that are some key additions to the Virtual Worker Manifesto which were proposed by Kent Sharkey that I still haven't gotten around to adding (sorry Kent).  In particular Kent offered this gem about getting things done:

If you're really busy, shut off IM (and probably also your e-mail client). Having your IM up, even marked as "busy" seems to just be an invite to people. Similarly, if you use Outlook, shut off the popup notification. You don't need to know the instant an e-mail comes in, it should be able to wait a while (previous manager's management style notwithstanding).

Now I know that this message is very pertinent to anyone working from home and I'll be sure to add it to the existing list real soon! 

Here's the full list of Kent's proposed additions:

    http://acmebinary.com/blogs/kent/archive/2006/09/04/810.aspx

I know that the "Don't eat crap" one especially applies to me - I now make sure that the fridge is full of healthy snackables such as: Carrots, Apples, and sliced **Watermelon. 

** The reason for pre-slicing the Watermelon is that it makes it easier to simply go to the fridge and grab a slice.  As opposed to having to cut up a slice whenever you want one - you slice it all in one hit at the beginning.

Link to The Phone Screen - Joel on Software

Not only do we have the Phone Screen at Readify, it is pretty much our entire interview strategy 

We normally start with a technical interview which lasts anywhere between 45 minutes to an hour and then follow it up with a shorter HR style interview for successful candidates.  In addition to this I normally ask that people submit a photo of themselves and, sometimes even a snippet of some of their code.

Joel's approach differs slightly from ours but the desired result is undoubtedly the same.  Regardless, reading about Joel's technique has given me some ideas for strengthening how I've been conducting interviews.

At Readify we have what we call a live-in office which is located at Docklands - a couple of modern apartments that overlook Testra Dome and the waterfront and which serve a dual purpose.  During the day these apartments are the offices for any staff which want to use them.  During the evenings and on weekends they serve as accomodation for anyone who happens to be travelling into Melbourne for work or pleasure. 

Having a live-in office changes the dynamics of everything just a little bit.

How many of you can say that you've had a 7:15AM business meeting with your CEO while you were standing at the door and he was lying in bed! :-)

Seriously though, I always love coming down to Melbourne for work.  It's a great meeting point to catch up with the other Readifiarians and spend the night having whiteboard sessions and dreaming about unbuilt software application.

We've been updating our website to a new DNN engine and with new graphics and the results are in:

    http://www.readify.net/

I like the fresh look and the site is much easier to navigate.  My favorite section is bound to be the Tech Zone because that's where we'll be putting all of the cool toys that we build :-)

Well done to the guys'n'gals who got this site across the line in time for the announcement that we made the BRW Fast 100!

    http://www.readify.net/Default.aspx?tabid=78

Woohoo!

The Virtual Worker Manifesto

Working from home presents some significant challenges beyond those that exist when working from a traditional workplace.  Many of those challenges relate to how we communicate effectively with our co-workers and more importantly how we address the notion of living in our offices.  In this article I’m presenting a number of things that should be taken into account when making the shift to becoming a virtual worker so that you can enjoy the best that it has to offer.

1) Email work items to colleagues anytime, just don't expect an immediate response.  There's no guarantee that they are on the same cycle as you anyway. ;-)

2) Don’t phone your work colleagues about work related matters after hours.  Family time is precious.

3) Zero your Inbox daily.  Or put better… stay on top of things.

4) Subscribe to the alerts – blogs, IM status changes, shared calendars, etc – of your co-workers to keep abreast of what they are up to. This will reduce the amount of time that you need to spend writing emails and engaging in phone conversations and will reserve those activities for only special occasions.

5) Delegate anything that you can delegate before starting your own work – this is no different to the bricks and mortar rule.

6) Don't spend your entire day processing email.  Go for extended periods where you are physically disconnected from your email client.  You don’t need be the author of each alternate message in an email thread :-)

7) Take advantage of the best of what virtual has to offer.  Have lunch with your family.  Work from the beach.  Grow a beard.  Chill out!

8) Shower daily.  Yes… DAILY - and while you are at it get out of the house too!

9) Invest in creating a pleasant working environment.  Don’t skimp on your virtual habitat.  Buy a water cooler, a nice painting, and invest in having a pleasant view.

10) Re-think how you communicate with your co-workers and choose your communication medium wisely.  No need to choose a synchronous medium when an asynchronous one will do.

11) Switch off, and I mean off.  Switch off the phone, email, IM or all of them, any time, day or night.  We are all virtual professionals and as such do spend extended hours on line, but at the same time if we get bumped to voicemail, or have to wait for a reply to an email, nobody is going to think that you are slacking off, or unresponsive.  We all need to switch off whether to focus on a particular task or just have time out.  I do.  (Added by Graeme Armstrong 6-Sep-2006)

In my recent post about the virtual office I mentioned that there are several ways to connect with your digital co-workers - one of which is to view their online presence message on Instant Messenger.  In the comments of that post, fellow Readify guy Andrew Parsons touches upon what is potentially the greatest challenge of the virtual office when he writes this:

I agree completely Darren and putting this blog entry together with your other one you can definitely see the upside of running a virtualised office full of night programmers. We're always available at pretty much any time 24x7, we have Live Messenger, phones, email contact, etc.

24x7 eh?  Are you up for that?  Always at your desk or digitally strolling the corridors of your virtual establishment.  Able to be pulled up at an instant to chat about progress on a piece of work or just to simply chat about the football.  Available: On Demand.

When your office is your living room you are never far away from email and the opportunity to "process" it.  How do you step back?  Relax?  Enjoy?

Go on, answer it... you know you want to.  It's only 11PM right... just a quick response.

At times my family and friends have asked about my job and how I manage to stay in touch with my co-workers.  For example, my mother simply cannot comprehend that we don't share a physical office and argues that I couldn't possibly keep in touch with my workmates... However I'd argue against that though because there are so many ways to keep in touch with people if you know what you're looking for :-)

For example by looking at Live Messenger I see that Grant is probably looking for help moving into his new house this weekend.

I've stopped wearing a watch :-)

At Readify, we get involved in a lot of audit/review style engagements.  Performance reviews, Architecture reviews, Database reviews and Security reviews.  Internally we now have some useful documents floating around that describe the things that should be done an these kinds of engagements.  Today, while browsing Robert Hurlbut's blog I discovered that he has also published a checklist of things to do when engaged on a security audit:

    Security Code Audit

In addition to that he also linked to an article by Michael Howard which describes some common ways to perform security reviews on code:

    A Process for Performing Security Code Reviews

List<Feed> feeds = Readify.BlogsphereRunner.GetCandidates() ;
... // obfuscated selection process
DotNetDude dude = Hire( feeds[0] ) ;
Readify.Employees.Add( dude ) ;
GUIHelpers.Render( dude ) ;

GUIHelpers.Render( dude, new BorgTransformer() ) ;

Welcome aboard Geoff.

Paul Stovell has been monkeying around in the SUB source (which is now being hosted on the Readify internal TFS repository).  I know this because I of all the check-in notifications I've been receiving :-)  So far, in just a couple of days he has:

• Added a new SQL Server data provider - complete with sql setup scripts.
• Refactored the code base and made it easier to re-theme.
• Got the MetaWeblog API stuff working - as was evidenced by his first post from Word 2007.
• Added a new standard theme named VistaBlue - which is the one that Paul is currently running on his own blog.

In addition to getting his check-ins (with associated useful check-in comments), I've also been seeing the successful build notifications coming through every time that a check-in is made.  This is because of the new continuous integration tasks that Chris Burrows has now got working on our TFS install - which I'll blog about later.

Go on, place your mouse over a Readify consultant... you know you want to :-)

On Sunday Grant posted up that he had done 34,000 steps in the Global Corporate Challenge; he also finished by asking: "Who’s up to the challenge of beating that? I need a new goal."

Well, I'm always up for a challenge, so this morning I awoke at 5:45AM when it was still -6 degrees Celcius outside and went for a 3 hour walk.  I walked from Weetangera, through Cook, up Bindubi Drive to Belconnen Way, down to DSTO at the back of Bruce, down to Lake Gininderra, through Westfield Shopping Center and then back to Weetangera.

At lunchtime I walked for another hour or so and then did another hour at dinner time.  Finally tonight I did an hour and a half of Hockey training (again in sub zero degree temperature).  The result is this:

Not bad eh? I was thinking about it though and I think that I wouldn't mind doing a whole day walk - maybe 9 or 10 hours - and trying to crack 60 or 70 thousand steps. At least that would give Grant something to aim for ;-)

I see innovation almost as a currency.  Once you have innovated then you have money (or fuel) to spend.  Basically, you spend time creating and being innovative and then you spend what you gained from that.  The important part here is what you choose to spend that gain on.  You can either spend your currency on the next round of innovation or, you can choose to die. 

Once the currency is gone you are left with a dead carcass to feed from.  This is similar to vultures picking from the bones of a once flesh-filled kill.  Chances are that you've seen or even worked at a place where innovation ceased to exist and I can tell you that from the very moment that it did, death held that place in its icy grip. 

The most common reasons and excuses for not innovating are:

• I don't have time (to innovate)
• I need to be trained on that (before I can innovate)
• What's the point (of being innovative)
• It's too risky
• It costs us too much

I've started taking a much more senior role both at work and also for the hockey club that I play for this year and it's interesting to draw the analogies between work, life, and play.  One of the most interesting parallels that I've been focussed on lately is that of having a game plan.  Consider how often you see talent-laden teams have a good run through the season only to fail during their finals campaign.  Often I put this down to the losing team simply not having the right game plan to pull of the victories that count.  I see the season as a time to perfect the game that you plan to execute when you make the finals and not simply a time for staying fit.  In fact, I argue that, if you don't have a winning game plan ready for execution when it comes to be finals time that you might as well lay down your hat and wait for next year to come around.

So much do I value the importance of building a game plan that I'm more than happy to suffer a losing streak - even a season long one - if it means getting everything lined up.  Achieving the right game plan requires a great deal of attention to detail.  You must identify players strengths and weaknesses and put them into positions where they can compliment one another.  You need to have a strong senior group who have the stamina and the focus to assist in ironing out weaknesses and looking for new strengths.  You must have the right training drills that keep the players sharp and their skills honed - and the drills should be interesting and varied too so that they prepare the players for a wide variety of situations that they will encounter during a game.

Building a champion team requires all of this and it also requires time too.  If you've been given the role of building a finals-winning capable team then you should set yourself goals. 

The first goal should be to instill what I call "the game plan" upon the team.  This means that the team will have formed habits that are deeply entrenched and these are the habits that form the basis for everything that sits above them.  This includes things such as each player knowing and owning their position and also the fundamental way that the team communicates. It also includes some standard patterns of play - such as how to transfer play from one side of play to retreat and attempt an attack via the other flank.  From having this game plan as a base the team gains a mental strength that comes from knowing that they will never be in unfamiliar territory and when they are under pressure they will know to fall back to the basic game plan at all times.  The basic game plan should be constantly re-iterated to the team through drills, mentoring, and basic coaching means such as whiteboard sessions until it is so ingrained that the players would feel naked and clueless without it.

The second goal is to build the strength of the team.  Even a team with a great game plan will come unstuck when all reserves of energy have been depleted.  Fatigue can easily remove a players ability to execute their role effectively and so it is important that the team has enough reserves of fitness to last out the entire game.

Finally, when the team is fit and focussed you should introduce new thinking.  This new thinking can come both from within the team as well as from external sources.  In the last great team that I was associated with we brought in current and former Olympians to talk to us and to monitor our training sessions.  Having these kinds of people assisting helped us to stay focussed in striving for excellence as they were able to work with us to iron out minor deficiencies and also because they served as a source of inspiration to us.

Almost everything that I've said in this post relates as equally to work as it does for hockey.

As Mitch mentioned in his post from the other day, I'm currently looking at ways to emulate a daily scrum meeting in our virtual environment.  First a thing about SCRUM...  SCRUM is designed to encourage projects to move ahead in an unhindered manner and this means:

• trusting your team to do the work
• remove barriers - such as beauracracy - so that the team can spend its time being productive
• giving team members freedom to make decisions - so NOT micro-managing the team

The daily meeting is an important element of SCRUM as it allows for the team to get together and discuss issues and cross-pollinate ideas.  It's also a sanity check and therefore involves two important questions:

1. What did you do yesterday
2. What did you do today

Being virtual is something that we take great pride in at Readify and so creating solutions that solve virtual collaboration problems is very much the space we enjoy playing in.  I hope to talk more about how our virtual SCRUM meetings evolve and to give some insight into the methodology, tools, and various other things that we use to enable engaging, meaningful virtual scrum meetings.

NOTE: Maybe now that I've discovered TechTalkBlogs I'll be directed by the number of Thumbs-Up votes that this post gets when I decide how much emphasis to place on cranking out future posts on this topic :-)

When we get an applicant for a tech role at Readify we put them through a tech interview.  Basically the tech interview involves having a phone discussion with a Senior consultant so that we can ascertain the technical savvy of the applicant.  We generally rotate the tech interviews among a few of us and it will depend on who you interviews you as to the type of questions that you get. 

One of the questions that I always ask is for the applicant to tell me about their favorite personal project that they have going right now.  It's a bit of a loaded question I suppose because of how it assumes that they do have a personal project - but that's almost my point.  Having a personal project (or more than one) is a trait that is shared by every developer that I respect and so I rate it rather highly.

As Mitch writes, we are nearly always hiring.  Readify is always looking for technical specialists who enjoy working with .NET and other related technologies.  But as Mitch says, the hiring process is often more of a long conversation than a short, sharp process.  Because of this it's important that we always have a pipeline of people that we are talking to who are potential Readify material.  If you ever feel that Readify is the type of company that you would like to work for and you are interested in discussing what it's like to work at Readify or, you'd simply like to put yourself on our radar, then drop Mitch an email from the link on his blog post:

    http://notgartner.com/posts/4190.aspx

It's official.  Tonight I fly to Melbourne to start the handover process for my new role.  It's still with Readify of course, but I'll no longer be a tecchie consultant resource.  Yup, that's right - I'm an overhead! :-)

My new role will see me looking after resourcing and scheduling and also managing internal projects.  This is a very exciting move for me as it allows me to combine my inner-Accountant with my outer tecchie to hopefully do some interesting things around process automation.

Some of my first tasks will be to help get our CRM implementation up and running and also to define some new internal processes.  I'll probably also start to take the reigns of the resource scheduling this week so, if you see any Readifiarians wandering around the streets looking lost, you'll know that I've probably broken something :-)

Wow, you miss all the cool news when you head overseas for a week.   I was running through Outlook this morning and noticed that we've announced ReadiFridays.  Mitch also blogged about this here.

ReadiFridays is a concept that we're really excited about because it will enable us to get out and talk to groups around the country about the really important new technologies in a way that allows plenty of interaction.  Derrick is kicking off with the first ReadiFriday which is about Real Time Collaboration and LCS.  Read the agenda for that here (you can also register to attend from this page):

    http://www.readify.net/Default.aspx?tabid=396

You can browse here to learn more about the ReadiFriday concept:

    http://www.readify.net/Default.aspx?tabid=392

For me the best part of ReadiFridays is that we get to talk about the new technologies that we are the most passionate about and I think that will make them different to anything that has come before.

Congratulations G and E!

Last week I was lucky enough to be in Adelaide to teach our Professional .NET course.  The students were great and hung in there exceptionally well.  Even on the last day (Day 5) when we were discussion things such as SOA and design principles they were still fully engaged and asking lots of questions.

I took the following couple of pictures with my phone.  They are diagrams that I drew on the whiteboard and I wanted to keep them to remind me of how I represented .NET and ADO.NET.