A Brief Discourse on Morale and Web Development (Continued)

Often we developers are handed brown-field projects that have one or more common, morale-crushing problems that I outlined in a previous post—in fact this is probably the most common case because developers will very rarely abandon a project that is going well.

The solutions to these problems are frequently quite simple, but also a bit arduous. I outline them below:

• Bad Code – The only way to deal with bad code is by re-factoring it into good code. There is a strong temptation to attempt to fix the whole damn program in one pass, but I find this is rarely the solution. Instead pick one very small subsection of the program or object. Declare that section to be the "good neighborhood" and point that out in comments. Then re-factor it carefully and thoroughly. One game I play with myself when re-factoring code is to see how many lines of code I can reduce it by. Let all the other developers know that if anyone puts sloppy code in the good neighborhood there will be hell to pay. Now that you have a beachhead of good code, slowly expand your efforts. Start fixing things that are tightly coupled with your good code zone, and then things that are loosely coupled. Make sure that the expanding circle of good code is clearly labeled so that it is always obvious if a developer is in a good code neighborhood or a bad one.
• Unpleasant Libraries – The simple answer is to write a wrapper class that behaves the way you want the library too. A good trick to doing this is to write some sample code that calls the library they way you want it to, not the way that the library is actually called. Once you have a really clear idea of what you wish library calls looked like, go ahead and write a wrapper that makes the library behave that way (or close to it). This tactic is great if you are just introducing the library, and are being forced to use it, but it also works if the library is already heavily integrated with the project. In that case simply use the wrapper whenever you write new code, or re-factor existing calls. If you have established a "good code neighborhood" be sure that all of the library calls in it use your wrapper.
• Out-of-date Comments – The most important thing that can be done is to make sure all of the developers know that the comments are not trustworthy. Once this is the case, developers can start to rewrite the comments block whenever they work on a section of code. Comments should explain why something is done, which rarely if ever changes, not how something is done.
• Oversized Milestones – Sometimes you just need to break things down for yourself. Break that milestone down into a whole bunch of foot-pebbles. Little tasks that will take 4 hours or so to complete. This process can take a little while but once it is done, I tend to find work progresses much more quickly. It can also often reveal unrealistic time estimates in a way that larger planning chunks fails to. This brings us to...
• Falling Behind – When a project starts to fall behind, you must realize, you cannot bring it back up to speed. Don't kid yourself about working longer hours, which will just produce lousy code, or adding developers, which will simply slow you down. There are only two realistic solutions: cut features or push the deadline. The next thing that people get wrong is how much they need to push the deadline by. If you have used up half of your time, and your project is only 40% done, it doesn't mean you need 10% more time, the amount you're behind by, it means you need 20% more time, the amount you are under-delivering by. That’s a bare minimum; keep in mind that projects tend to really go sour during the last milestone or two, so if you starting to experience problems before then, you probably want to give yourself a bit more time. Most clients understand that sometimes it takes a little longer to get a high-quality result. What they don't understand is a development shop missing deadline after deadline. It's critical that you ask for all the time you need if you start to fall behind, so that you only need to ask once.

In an ideal world, developer morale would always be high and every project would run like clockwork. But we know from experience that the reality of web development can be very different. The first step is admitting you have a problem. Then take decisive action to resolve it, even if it means re-factoring code and/or deliverables. Nobody wants a miserable project, not your developers, not your project managers, and especially not your clients.