« April 2005 | Main | June 2005 »

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:

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 10:45 AM | Comments (4)

May 06, 2005

The Silent Minority

<rant>
What gives with Mac owners being complete twats!?! Feeling compelled to evalgelize it's merits to all the poor souls who haven't discovered the faith? I'm also of the fold, but I often get comments along the lines of "oh, I didn't know you owned a Mac?!", based on the fact that I'm not going on and on about it from dusk 'til dawn - apart from this blog of course :-)

So to all my Mac bretheren out there, if people aren't buying the spiel, give it a rest. They either get it, or they don't. And if they don't, they sure don't want you harping on about how much better your life is than theirs. Mac owners risk becoming the Mormons of the computing world. Live and let live, I say, or do unto others...

Likewise, I suspect that there must be a law somewhere stating that every Ruby programmer be a vocal and strident advocate of their shiny new toy and wo betide anyone who doesn't see the light.
</rant>

Posted by Andy Marks at 11:21 AM | Comments (1)

May 04, 2005

Standup Patterns

A blog I was reading the other day about dysfunctional standups reminded me of a pattern we'd adopted a couple of projects back:

Name: Pair Report

Motivation We were pairing 100% on this project, rotating pairs roughly every day or so. Because of the nature of pairing, often the first person of a pair who spoke at standup normally covered most, if not all, of the news from the pair, leaving the second person to comments such as "pass", "what he/she said" or "nothing to add". When the pair was geographically split within the standup circle, this forced a context switch of the listeners to remember what the second comment was in reference to

Implementation: Simply, each pair stands together in the standup circle, so related comments come immediately after the originating comment. The result is a more logical, cohesive report from the pair.

Variations: This pattern relies on a relatively low pair rotation. If you have pairs rotating several times throughout the day, this pattern can lead to mad dynamic clusters forming throughout the standup as people swap to stand beside their various partners. We lived with this normally as it didn't cause undue turmoil.

Posted by Andy Marks at 10:55 AM | Comments (0)

May 01, 2005

Oh, you mean that Melbourne!

Further to my previous blog, much kudos to Simon Harris who was also struggling to get the Dashboard weather widget to recognize Australian cities straight out-of-the-box, but who persevered to a solution. Must say, I prefer the Konfabulator version of this widget which displays the country as well as the place name.

Given his findings, perhaps the Brisbane that was being reported was this one.

Posted by Andy Marks at 01:20 PM | Comments (2)