Ayende @ Rahien

Refunds available at head office

Meaningless code quality, part 2

Here is the next slide in my presentation.


Code quality is a hard metric, it can be backed up by numbers, if you need to. Fairly often, it is measured by gut feeling and "this is a mess".

One interesting problem with code quality is that you generally don't have a good way to measure the maintainability of a particular solution, regardless of its current code quality.


Konstantin Spirin
08/25/2008 04:55 AM by
Konstantin Spirin

A good code quality metric exists - it's WTFs/minute.

Easily googlable.

For example,


Peter Ritchie
08/25/2008 01:29 PM by
Peter Ritchie

Metrics about coupling and dependencies are a good indication of maintainability. But, they're not foolproof.

One thing I've learned over the years is to never underestimate people's ability to write lousy code to make metrics look good.

Gian Maria
08/27/2008 10:22 AM by
Gian Maria

Metrics should not be known by developers, if you do not known the metric you cannot write code only for the sake of having good metrics. But in the end metrics themselves are not so useful.

Code quality can means different things, I think that we should speak of Code quality in a team, meaning that the code have good quality if everyone in the team can look at it, and understand how it works and most important, he can modify it with good confidence.

Clearly that are some factor like number of bug found that can be also a good starting point to measure quality of a particular piece of code.


Comments have been closed on this topic.