+972 52-548-6969
The only metric that counts: Maintainability
time to read 1 min | 113 words
There are a lot of code metrics that float around, measuring lines of code, code complexity, number of classes/methods, test coverage, etc. The important thing there is to remember that all of those are fairly meaningless.
When measuring the quality of a code base, maintainability is the only thing that I care about in a code base. It breaks down to a lot of smaller values, but in the end, I look at the maintainability score as the sole parameter that I care about.
Tests helps, and intent revealing, well factored code is manna from heaven, but it is important to remember what they are there for. To make the code maintainable.
Comments
metrics need to be measureable, how would you define maintainablility as a metric operationally; in a measureable way?
I understand that it's kind of a subjective metric, but just out of curiousity, do you have any tools that you reccomend for measuring this? The one built in to vs2008 (team suite edition at least) left me kind of scratching my head, but I find that the one that ships with the DevExpress DXCore add-in is really helpful at gauging this.
Joe,
I like the DevExpres stuff with its maintainability score.
But I think that the overall maintainability of a system is something that you can only tell when working on it, it is hard to figure it out using some technical means.
I can't agree with you more Oren. The problem is that what makes code maintainable to you and I can end up being incredibly unmaintainable by someone else, especially if they don't have anywhere near the understanding of the platform, language, etc as we might.
To quote someone from this week who simply blew me away with this comment, "components (in this case, SharePoint WebParts) that are full of lots of classes and members (fields, properties, methods) isn't as maintainable as a component written with a single class and only a few methods (or one big Render() method)."
I'm still completely blown away by that comment, but it explains a LOT. That same person was still using C/C++ constructs within .NET to deal with errors, instead of properly utilizing .NET exceptions, so go figure.
In short, maintainability is all about the education level of the person needing to maintain the code. The more we can educate our peers on the "why" we do the things we do, and not just the "how", the sooner we will stop having this discussion.
The only metric that counts: customer satisfaction (I like to call it "happiness").
Yes, maintainability cant count towards this in the long run. But the one and only metric (eventually) is customer happiness .. all other metrics directly affect this happiness/satisfaction .. documentation, performance, ease of implementing new features, time, cost, reliability, accuracy .. and on and on .. they all boil down to that one thing ... and in the end , the customer is paying your wages!
Code maintainability boosts developer "happiness" in the short term, more so than it does customer "happiness" .. A quick fix/hack is a way of quickly increasing customer happiness but eventually some form of technical debt will occur, and that will start to affect the customer happiness negatively.
I believe it's our jobs as good developers to try to maintain a good balance between these states..
@Dave: Actually, your description of things is too simplistic, for several reasons. for example, I have been involved in projects with quite the opposite dynamic; i e devs get reinforced by rapid customer feedback (which is the ultimate happiness for most devs, that is why we do what we do in the first place) that works in such a tight loop that maintainability has no room.
as for maintainability in most cases, the dev team must continually argue and explain it's necessity. and customer happiness is definitely not the only metric that counts if you want sustainable development and low personnel turnover.
Nonsense.
Consistent adequate performance is more important than maintainability or speed. (bug resolution or program execution)
Customer satisfaction has little if any relationship to how code is written and is 8/10 to do with reliability.
Reliable communication (from developers or from the product) (note I didn't say resolution or quick)
Consider the likely use of the component when considering how much time to be spent improving maintainability.
Under designing and over designing are both high costs in soft dev.
But if anything can be considered a rule it would be that:
Any stop gap flexible component built in a rush will be reused in an inverse proportion relationship to the amount of time spent designing it originally.
Comment preview