« The Silent Minority | Main | Say It Ain't So! »
May 13, 2005
Is Quality Really A Lever?
I'd like to take a moment to ponder the use of quality as a lever during software development by a consulting company. I have to emphasize the last part because the consulting nature of this work is key to one of the issues around code quality.
Quality, along with time, cost and scope make up the four project control variables according to Extreme Programming Explained (aka The White Book). The general philosophy behind these variables is that project managers can fix/control three of the four at any one time.
Note: all references to "quality" from this point onwards are referring to "internal quality", that which is visible to the development team and which does not (necessarily) impact the external quality of the software itself.
The White Book then goes on to say that "the only possible values [for quality] are 'excellent' and 'insanely excellent' under the quite reasonable assumption that all developers want to produce high quality code because of the pride they take in their work.
However I'm sure I'm not alone when I say that there have been times where I and/or my team have been forced to produce lower quality code to meet time, scope and cost constraints. Sometimes I've had the bandwidth to redress these issues, sometimes not. Like most developers, I've been unhappy with these situations but have made sure the customer is well aware of the potential downstream effects of their choices.
Recently, I've had discussions with two learned collegues - I'll call them J1 and J2 to maintain some sense of anonymity whilst giving those in the know a fair idea who I'm referring to. They both have strong opinions on this matter and both viewpoints are completely valid; I'll paraphrase below:
- J1: We cannot compromise on code quality because of the potential damage to our brand as a professional services company specializing in enterprise software development. Irrespective of the pressures at the time of development, when people outside of the project look into the codebase and see obvious quality issues, we risk our reputation and future work
- J2: As a professional services company, we're obliged to perform the duties requested by the customer who engages us. If they insist quality is to be sacrificed in favour of more pressing needs (assuming we've informed them of the possible downside to their choice), then we're being unprofessional in deliberately spending their money on work that they haven't requested.
Two points further muddy these waters; the natural tendency of code quality to drop over time, and the ability of refactoring and a good test suite to help maintain code quality with zero extra cost.
Firstly, it's a well known phenomena that, left completely untouched, code quality will decrease at a rate somewhere between seafood left in the sun and plutonium. The best evidence of this is the frequent statements along the lines of "I just had a look at some stuff I was writing a couple of months ago... and God, it sucked! I cannot believe I wrote such dross!".
Secondly, a well-applied combination of refactoring and automated testing should greatly assist in maintaining code quality with little/no extra effort. The key to this is to get on top of these things early and have a high quality codebase from Day 1, rather than having to fight uphill after quality has dropped to an unacceptable level.
But irrespective of these points, I'm still tormented by the basic logic of the orthogonal opinions of J1 snd J2. As a default case, I'll (try to) write the highest quality code I can and keep improving that code whenever I have the capacity to do so. However, I'm now aware of the "bigger picture" view of ensuring our brand remains undamaged in the minds of whoever may be working on those codebases until their end of life.
Resolution: ensure the cost of maintaining code quality is as small at it can be, removing the need to consider it a task separate from development itself.
Posted by Andy Marks at May 13, 2005 10:45 AM
Comments
Sensational topic Andy. Any conscientious developer has mental battles on implicit quality almost daily. I'm inclined to roll with J1 moreso than J2, also because it engages me more as a developer and keeps me motivated. A couple of other points on the topic:
- The more you learn and become proficient at developing quality software, the faster it should become to develop quality solutions and less mental battles/moral dilemma's should ensue.
- Perhaps the best measure of aged codes quality is to quickly read and try to understand it. I'll always be able to say my old code is worse than what I'd produce today, usually because of new patterns or technologies I've learnt that make code more obvious, flexible and maintainable. Still, you can only do the best with the tools in your brain (and the collective teams brain) at the time. From my experience developers are primally tough reviewers, nearly is never good enough - I think thats a big reason people spasm looking at old code. Still, I'd be happy enough with my old wares if I could quickly scan through the packages, classes and a couple of interfaces/key classes and get the jist.
Posted by: blondie at May 13, 2005 02:01 AM
Hi Andy,
I'm a young architect based in Melbourne and I came across your blog while searching for a programmer/application developer. I have some good ideas to streamline architectural workflow which would require scripts and plugins to bridge a number of architectural softwares together. I think the main language would be Ruby. If you think you can help me on a contract basis, please email me for more info. cheers.
Posted by: David at May 23, 2005 09:17 PM
Andy,
Something rankles with me about both these points of view...
J1 - If forced to make a choice I would rather have a reputation for pragmatic responsiveness to my customers need than perfect code quality. If it is truely in the customers best interest to compromise a bit on quality then I will do it and what others may think is a secondary concern
J2 - Customers employ consultants to tell *them* how to do things, not the other way round. If, under pressure, the customer wants to do something that my experience tells me is not in their best interest, then I would not be earning my money if I did not try to stop them.
Is simply warning them sufficient if they are not in the best position to comprehend the ramifications? Would you expect to be able to insist that your builder only mix half as much sand with the cement in order to lower costs?
In the end it's a judgement call, but I consider it is a call best made by those charged with developing the software. Its what we get paid for...
In the end its a judgement call -
Posted by: Perryn Fowler at May 27, 2005 09:16 PM
OT: Andy, I know you are an avid biker.
How do you carry your laptop to work everyday?
I am a long time walk to work guy, but am thinking of switching to bike for days when I need to be quicker. I was thinking a "crumpler" bag might be the go.
Any help appreciated !
Posted by: Michael at June 9, 2005 08:08 PM
Post a comment
Thanks for signing in, . Now you can comment. (sign out)
(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)