We’ve just started a new project. We are at the very beginning and we still don’t work under pressure of time. And that’s great. Such slow start is a chance. A chance to set things up as you would like them to see in ideal world.
We use this chance to:
• Choose and verify tools used during development. Continuous build, unit testing, static code analysis, coding standards – all this things which should be on place but so often there isn’t enough time or you have to throw everything away because of some emergency. And if you try to do it in already settled environment it’s such a painful and long process.
• Design properly. Have you been in a situation when you just do your wild-ass guesses (aka rough early estimates) and suddenly you have to start coding because you’re a month behind a schedule before even a contract was signed? It is said that testing is the first place where you (unwisely) cut schedules. Well, designing holds a strong second position.
• Find time to discuss requirements. Is all clear? Yes? Good. Write it down. Go at least one level deeper to get more details. Another time write it down. Now, get people read it and understand it. Are there any questions? Of course there are. Congratulations, you’ve just eliminated some issues which would appear later and would be way more painful.
• Adjust project management techniques. Ensure you gather all the data which will point how much you miss initial estimates. Set workflow for work items which won’t be a pain in the ass for developers. Think what people pointed as problems during last post mortem session – do you always find time to use this knowledge to improve your projects?
Basically all these things are just simple ways to avoid or limit technical debt. If you start slow it’s much easier to set them up properly which soon will return in terms of team general productivity. Of course that does mean additional work if you compare it to impossible-to-meet ideal world schedule where everyone produces best of breed results with highest possible performance.
The reality is that projects with technical debt starts producing visible results faster but they soon lost their advantage and over time are more costly. Starting a project slow gives you an excuse to do a good job in this area. You can need one for your bosses and you can need one for yourself.