Which is easier? Bringing someone up to speed on the .NET platform or bringing someone up to speed on your business? This is the question that project managers should be asking themselves when converting an old project such as MFC or C++/COM to .NET.

This is not the first release for .NET. Indeed it has been released for five years already (not even counting the large Beta period). The number of assemblies and types to learn is enormous. That is a lot of knowledge to absorb. In fact the longer companies wait to go to .NET, the more learning they have to do.

The productivity gains from .NET are significant, but think of all that time spent just getting back to the level of competency where you are right now. When starting on a major refactoring of the current product, it makes more sense to keep only those developers who have a ton of accumulated business knowledge. Then hire a bunch of expert .NET developers and do a lot of paired programming to get the knowledge to transfer between the groups.

In order to produce agile software there are really two components that have to stay agile: the people and the code (which is ultimately the product).  If either one doesn’t stay agile the other one is doomed.  If the people don’t stay agile then there is no motivation to change the code.  If the code is not agile then it doesn’t matter how much the people want to change it – it is very difficult.  Both are required for an agile software company.

How do we go about making sure that our people stay agile?  The more time they are able to think (and code), the more agile they become.  Developers work best “in the zone.”  It takes about 10-15 minutes of uninterrupted time to get there.  One way to keep interruptions from occurring is to hold fewer meetings.  There are three fundamental practices that should be instilled in all called meetings.

1. Identify the required people and include an agenda in the invite.
2. If those required people are not present within 5 minutes of the meeting’s start time, cancel the meeting.
3. Finally, the person who called the meeting should always summarize the meeting appropriately.  They should also somehow publish the notes and/or action items from the meeting (Sharepoint? in the bug tracking system?).

If that seems like a lot of work, it is.  That’s really the point.  Because you shouldn’t interrupt people’s valuable time without a clear important goal.  If it is worth calling a meeting, it is worth doing it right.  If that serves to deter the number of people that call meetings, then that is a positive side effect.

Another great way to keep people agile is by pairing them together, and encouraging them to discuss possible solutions to complicated problems.  Pairing has a number of benefits involving skills transfer as well as offering two different viewpoints on the problem.

Agile people have versatile skill sets.  They are generalists.  They work hard to learn new skills and apply those skills until they end up with multiple specialties.  Over time of course a skill might be forgotten, but they could pick it up if need be .  One of the best ways to encourage this is by rotating people throughout the department.  Instead of keeping your web developers and your database engineers segregated and fixed, shake them up!  Training and conferences also help give people versatile skill sets.  Basically trained people make less mistakes.

How can we keep the code agile?  Agile code is healthy code.  It is easy to change.  Unit tests are the best way that you can assure that your code is healthy, and refactoring is the best way to assure that your code is easy to change.  When you have good well-trained people working on code making lots of changes, it becomes easier and easier to change over time.  As you have new people or poorly trained people working on the code it tends to get more and more difficult to change or fragile over time.  As people are able to take their time and make sure they do the job right (have only 2-3 things to deal with at any given time) the code tends to improve, and as people are harried by deadlines and release dates they tend to do a poorer job.  Peer reviews can also help balance this effect.  The person peer reviewing the change has nothing on their plate right now except for looking at this code.  If they do a poor job and let lots of stuff go, it might affect the other things they have on their plate later.  If they do an excellent job, it’s not going to take that much longer than the poor review, and there is a positive impact to future tasks.  So they are motivated to make sure they catch items and get them addressed.

I think one of the key things to push for is a lightweight framework that always makes sure that developers are doing the right thing.  Any rule worth stating is worth enforcing.  Also, program managers should be setting aside time to make sure that their code base is agile enough to support the changes that are bound to take place.  To keep the code agile you need a person or in the case of a ton of code maybe even a group of people that go around looking for ways to eliminate code and make it simpler.  This person(s) can spend their time trolling through the code looking for inefficiencies and areas to make common.  Over time this will pay off in a sub-linear rather than exponential increase in complexity.

I obviously try and convert software projects to good practices when I can.  Things like peer reviews, unit tests, acceptance tests, refactoring, etc. are all practices that make a big difference in the long term health of your project.

One of the biggest areas of pushback I see is that the project is already underway, and they don’t want to change practices or go back and fix things that are broken right now.  Instead they will “fix everything in the next release.”  This type of short sighted thinking is far too common in our industry, and it is not just the fault of the project managers. Developers have a responsibility to make the project managers see the light.

I liken this mode of thinking to sailing a ship filled with cargo with a hole in the bottom of the boat.  It really doesn’t matter to me if you choose to bail out the water in this release or the next.  But plug the freakin’ hole! Please just stop any more water from coming in!  Releases are rarely delivered on time, functionality often changes mid project, and all the while you are accruing more and more technical debt.  If left alone long enough this technical debt is enough to sink the ship.  I am not asking you to take the time right now to go back and fix everything, but you *do* need to change your practices so that you stop accumulating water.  Eventually the project is going to release, and the ship is going to have to sail again.  That is when you are going to notice whether or not you took a little time to fix the hole.  If you didn’t, then getting that next release out is going to be really, really difficult.  The code is going to be difficult to change, and you are stuck bailing out an entire boat filled with water before you can even start to load the next cargo.  To make matters worse maybe some good people leave or move on to other things after the release, because they know that they are surrounded by water.  Change is always hard, but often good practices take less time than bad practices.  By fixing the hole now, you aren’t really slowing down the ship, and the ship may even live to sail another voyage.