Brian Kennemer linked to my bent triangle post and noted that despite some bending of the triangle there is still a relationship between resources, scope and duration in a project. In this he is right - they are linked and it always pays to consider all three project aspects when considering a change to a project.
The main subject of this post is his comment:
“…higher quality code takes longer to write”
I think Brian is wrong. (As you read on, also note that my original post covered both code and process quality.)
The first, and most compelling refutation (at least for me), comes from personal experience. Once upon a time I was a senior nerd in a rapidly growing services organisation. We made moderately advanced business-rule processing applications for government. Since we were growing we often put people in positions of authority before we were comfortable with their experience or skills. We also had a culture that blindly ignored process. This unhappy combination meant that we regularly had situations where a project team was making lots of noise and working like maniacs but the project wasn’t getting closer to being completed. Invariably, a little bit of attention to process and a ruthless focus upon code quality resulted in an amazing acceleration towards the finish line. For me this was a clear hint that increased quality resulted in shorter project durations.
A second experience I had was in product development. I was responsible for re-writing/porting an expert system shell from Prolog to C++ and moving it to a client/server model. A colleague and I decided that we’d approach the job with an “alternative” philosophy of pragmatic perfection. We attempted to ensure that the system was perfect at all times for doing what it did. On reflection, we used a crude form of XP or agile development. Our experiment with this philosophy was kept largely secret since our managers would have been scared by such crazy talk of perfection. The result was the most satisfying and speedy development of a high quality system I’ve ever experienced. It was blissful. The development was done in less than six months and the code base is still going strong ten years later. Once again I’d seen quality and project duration positively correlated.
It goes without saying that an appropriate process will speed project completion. At extremes, I’ve seen projects delayed needlessly because nobody knew what was the highest priority task. I’ve even seen projects, after a couple of months of “emergency” work on key customer problems, realise that they can’t find the list of key problems they were working on. These are dramatic examples of process failure slowing down a project. Less obviously, using a process that is understood and sympathetic to the experience of everyone involved will improve speed since everyone will be reading from the same hymn sheet.
I almost can’t comprehend how code quality can slow down development. In fact, I almost define code quality in terms of development speed. Almost. I actually think of code quality as consisting primarily of correctness, consistency, maintainability, understandability, and approachability. These things have a direct bearing of how quickly something can be developed. Code that is arcane or simply incorrect slows down successful delivery of a project. Likewise, code that is inconsistent or random in its structure slows down projects. Of course, if you disagree with my definition of quality then it doesn’t help to show that quality increases project speed.
I can imagine some forms of “false quality” slowing down a project. In a previous post I discussed the danger to projects of unbalanced perfection. Some people focus upon a single aspect of the quality spectrum and maximise this aspect at the expense of other aspects of the project. This results in overall quality being lower or project delays. I think that it is this type of over-maximised quality (or false quality) that Brian is referring to when he says that “quality takes longer”. I honestly can’t conceive of true, needed, balanced quality actually slowing down a project.
Am I wrong?