|
|
Re: The Code Quality Myth
|
Posted: Feb 26, 2005 12:54 PM
|
|
> I hear you, but it seems that what you are saying and what
> Frank was saying in his original post are significantly
> different.
On second thought, I just reread Frank's post and may see your point. Frank writes, "When we spend time to make our code high quality, we justify that effort by saying that the work would provide some business benefit down the road. The trouble is, code quality, by itself, seldom results in any measurable business return on investment..."
I do believe there is a business return on investment for quality code that manifests itself as developer productivity and morale in the future. I am certainly happier when I get to work on quality code with a team that cares about quality, and that by itself may help me be more productive and less likely to quit my job and go elsewhere. That is value for the business: the programmers are faster and happier.
Frank didn't say "return on investment," though, he said "measurable return on investment." Programmer productivity and morale are not so easy to measure, and it is not so easy to figure out how that might have affected the bottom line in the previous quarter or year. And you certainly can't measure something that hasn't happened yet. When planning your current investments you have to make judgements of what value investing in code quality now will get you down the road, and use that to decide how good is good enough.
I have a story somewhat similar to Peter Hickman's story of a codebase that got so bad it became a business crisis. Peter said they were forced to start over from scratch. Where I worked the software was for a machine that was planned to be obsoleted in a few years. They were designing a new generation of machines, and in the new generation the old software wouldn't work anyway, so they were writing the software for the new generation pretty much from scratch.
The code quality of the software that ran the current generation of machines, the ones being sold at the time, was very poor. Our favorite thing to point to at the time as an example of the poor quality was an 11-page while loop, which was critical part of the functionality of the software. The poor code quality didn't just frustrate us as programmers, it also seeped through to frustrate users. In fact, the software crashed so much it was starting to hinder customer acceptance of these machines (each of which cost about 1 million dollars). So the company decided to create a "task force" to clean up the software. Before the task force there were about 3 or 4 programmers working on the code, and they brought in another 8 or so, plus a manager to lead the task force full time. We worked about three months if I remember right, and were asked to come in on the weekends.
So this company invested a lot in improving code quality because there was a business crisis. Not only were they paying about 12 developers full time, 8 of them had been pulled from other projects that were now not making any progress. But here's the thing: Our job was just to get the software stable enough so that it wasn't hindering acceptance anymore, and so that the problem wouldn't arise again in the next few years, after which the product would be obsoleted. And we did that, but afterwords, that 11-page while loop was still an 11-page while loop. Where before I would have given the code an F, after the task force maybe it would get a D. That D code was deemed good enough to meet the business need.
Some may argue that if the code quality had been high from the start, then the crisis would never have arisen. That's true, but we can't go back in time and B, C, D, and F code exists today all over the place. This organization did seem to learn that they needed to invest in quality, because they spent a lot of money trying to do a better job with the new generation of software. They adopted a formal methodology: Yourdon/Constantine. We were all sent to classes to learn it. They bought everyone an expensive Sun Workstation and a $25,000 a seat CASE tool. That team spent months and months drawing bubble charts, then structure charts, before finally starting in on the code. I don't know how the code came out, because I left that company, but I could see that management had decided that quality code was worth something to the business.
After the task force, I still worked on that D codebase for a while before moving to a different project. And we basically accepted D quality, because it was good enough in the business context. If we had an enhancement to make in the 11-page while loop module, we didn't bother taking the time to clean up that while loop, we just accepted it and made the change as best we could. I do believe that had the company continued the task force a few more months that we could get the code to C or eventually B. And there would be a return in terms of more productive and happier programmers, but it was deemed a better return on investment would likely be gained by letting two thirds of that team go to work on the new generation of software.
|
|
Previous Topic
