The Code Whisperer

Practical, on the ground advice for efficient software development

Archive for October, 2008


The Importance of Finishing

Over the summer one topic has come to light several times - the importance of finishing what you started. It’s very easy to get distracted on medium and long term projects and get pulled into the exciting start of another, or just get fed up with the current project. You can see this in work and hobbies, the classified section of car restoration magazines has a number of unfinished projects for sale.

Planning is a vital weapon to fight this attrition. Planning achieves a number of things aside from knowing when you are going to finish:

  • By walking through the project a number of times you are more likely to spot where problems can occur than if you carry on without planning
  • You have considerable more confidence in what you are doing as you have been through it several times on paper and in your head
  • Provided you re-plan, a diversion to a different project, whilst disruptive, means you know when you are going to finish the original project and what is required to complete it

I recently carried out some consultancy for a software development company that had 3 bug tracking systems and 2 source control systems on of which had numerous databases scattered over the network. Project documents were held on a Sharepoint server, one of the bug tracking systems and in several of one of the source control system’s databases. For the source control system there was an upgrade in place and to be fair there will always be 2 source control systems so that the previous versions of code are kept, but no plan to migrate from one to the other, so you end up in limbo where the vast majority of a project has been migrated, but not all of it.

In this case there was insufficient planning involved in the move. Problems were identified but not acted upon, leaving it until the physical migration to establish the best way, but which time a fix had been put in that meant some files were not under the new source control system. It works, but only when the developers know the tricks. When staff turnover is high this sort of information and the reasons behind it get lost and a temporary fix becomes permanent because “that’s the way we’ve always done it”.

Part of the reason my kayak trip along The Thames took so long to prepare for was done to constantly walking through and revising the plan that covered leading up to the day and the day itself. The result was that the day ran smoothly with eveyone knewing what they were supposed to do and when.

Finishing a task and striking from the list always feels good, there’s no nagging about it in the back of your mind, which frees up thinking power for the next task. If you do have to divert, make sure you continually update the plan to reflect the time taken on the diversion and put down enough information so it can be picked up again. Don’t assume you’ll remember the little details, often the time lag is longer than you expect.