February 27, 2008

...Learn TDD with Codemanship

Quality Trends Can Reveal Inadequate Refactoring Effort

A less pithy, and arguably far more constructive, answer to the question "are we doing enough refactoring?" can be find by examining how the quality of our code changes over time.

Take package-level coupling and cohesion, for example. if we want to objectively gauge if we're doing enough to keep packages cohesive and loosely coupled enough for our requirements, we can monitor those aspects of quality as the project progresses and identify where the trend might be headed.

Let's say, for example, that our goal is to achieve a certain maximum average level of inter-package coupling and a certain minimum average of package internal cohesion when our software is released.

We can add these two metrics to our code quality dashboard, and measure them every day, or every hour, or every time we run our unit tests. How often we measure it depends on how long you're happy to go before doing anything about potential package design problems. personally, i favour continuously monitoring code quality, because I favour continuous refactoring and I need this kind of feedback to help guide me in my refactoring efforts.

Anyway, however often you choose to measure code quality, over time you will doubtless notice a trend towards lowre quality as the code grows and evolves. That's just natural code ageing, and it happens to even the best development teams.

But better teams' code tends to age slower, because they put more effort into keeping it "young" as they go.

If the trend tells you that inter-package coupling is probably going to be too high by your release date, then you should consider putting more effort into optimising that aspect of quality. Likewise for package cohesion, or any other aspect of code quality you deem important enough to monitor.

Try it. Select a a handful of code quality indicators- like method length/complexity, or code duplication, or class/package coupling and cohesion, or package distance from the main sequence. Choose indicators you feel will give you at least a rough feel for the quality of your code. Take regular measurements - as often as you think you need to - and record any trends. You will also need to agree some targets for what levels of quality you would be willing to accept at some point in the future (e.g., at the next release, or 6 months from now, in a year from now, in 5 years from now, and so on).

Then target your refactoring efforts to try and ensure that your trends fall within the margins that would be required to meet your those goals.

I think you might be surprised at just how quickly code can age, and just how much refactoring effort is really required to keep your code in good enough shape.

Posted 13 years, 4 months ago on February 27, 2008