January 8, 2008

...Learn TDD with Codemanship

Measurement Can Cause Loss Of Swagger

One of the more rewarding aspects of measuring software quality is that many teams discover that, while they're not about to win any prizes for the quality of their code, it's actually not that bad. Especially when they realise that, compared to other products, their's is average or better. Often they expect the worst, and - after they've got over the initial shock of having their pants pulled down for everyone to gawp at their most intimate parts - they are relieved to discover that the teams around them don't have much to boast about, either.

On the other hand, some teams have built up an expectation that they are actually delivering much better code than they really are. They may have developed a certain swagger, thinking that they are more gifted in the trouser department than their peers, and this illusion is shattered when they discover that, actually, their code is average too.

And they don't take too kindly to being exposed as average. I mean, surely after all those stand-up meetings and retrospectives and all that pair programming and all those planning sessions, the code we deliver must be better?

Well, sadly, no. Not necessarily. You still have to understand things like architecture and design, and testing, and performance engineering, and usability, and configuration management and so on. And you still have to apply this knowledge with skill and with discipline. And you still need feedback on how well you're doing, no matter how good you think your code is. You always need feedback. Objective feedback. Early and often. Indeed, nothing short of continuously.

"Agile" teams can be especially hostile to being exposed in this way, since they often put an unjustified amount of faith in the principles and practices and are amazed to discover that, first and foremost, you have to be good at developing software - and that means pretty much everyone who touches the code - and that requirements doesn't go away. I certainly don't trust myself enough - as a sort-of, kind-of Extreme Programmer - to work without continuous feedback on every quality goal I've set myself. If maintainability is important, I monitor it continuously as the code evolves, just as frequently and as habitually as running the unit tests. And then I address maintainability issues as soon as they arise.

Posted 13 years, 5 months ago on January 8, 2008