Other than the number of bugs found, how do you measure software development quality? I'm looking for something on the positive side.
Wouldn't MTTB be Mean Time To Bug? :)
Craig
2008-09-08 21:06:44
+5
A:
Looking for metrics? They don't work. Are your users happy? Then you know...
Carl Seleborg
2008-09-08 20:42:09
Yes. You need happy customers.But how do you quantify their happiness. How can you use their happiness to evaluate any refactoring work? Only way is to have an extensive suite of unit tests to prove that your refactoring hasn't broken anything.
Rob Wells
2008-09-08 21:11:20
What's the point of having bullet-proof unit tests if you can't get the features right, and your users spend their day complaining about your tool?
Carl Seleborg
2008-09-08 21:26:36
This is a bit simplistic. If happy customers is everything you care about, just give them crappy software and a cheque for a million euros. That will make them happy, but that doesn't mean you are delivering good quality software. In other words, happy customers *does not imply* good quality software, although good quality software tends to enhance customers' happiness. Let's not oversimplify.
CesarGon
2010-10-10 12:10:15
A:
Of course, no idea how you'd measure any of these, but I suspect these are important metrics too:
- How much other developers like working on it?
- Hoe easy it is to maintain?
zigdon
2008-09-08 20:43:08
A:
Longevity.
I've had jobs replacing "legacy" systems that had been in place — practically untouched — for a dozen or fifteen years. (For DOS programs, this is thanks in part to Microsoft's extreme commitment to backward compatibility.) It's a testament to those systems when just one or two needed features finally motivates the upgrade.
In the right home, a great app can live as long as a healthy mutt.
harpo
2008-09-08 20:53:13
+1
A:
Your version control holds lots of information about the code.
When something's been changed a lot, either it means there's lots of bugs or perhaps it just means it's frequently involved in new features.
However when something's been left alone for a while (6-12 months?), that means it's stable and it might also mean lots of other code depends on it.
So this is a positive metric -- amount of code that hasn't changed in the past 6 months. It's also instructive as a measure of risk -- if you need to change a file that hasn't been changed in 2 years, perhaps you should be extra careful not to break anything since lots of other code might now depend on it!
Jason Cohen
2008-09-08 21:00:27
"Stable" code could also be code that is just so bad that nobody wants to touch it. It could also be dead code (code that is not actually used).Beware of using this as a metric.
Kristopher Johnson
2008-09-08 21:28:17
+2
A:
G'day,
There are a whole stack of measures of software quality.
Off the top of my head I can think of:
- McCabe Cyclometric Complexity - basically a measure of the number of linear paths through code.
- Levels of indentation - a measure of complexity when looking at nested decision statements.
- Distance from declaration to first use - how many statements exist between where a variable is declared and where it is first used.
- Comment percentage - how many lines of code are comments compared to source code.
- Percent test coverage - as a percentage of lines of code, how many are exercised by your suite of tests.
- Path test coverage - how many paths of execution are exercised by your tests.
- Unit coverage - how many individual units, classes, packages, etc., are exercised by your unit tests.
There are many more metrics than can be measured, these are some of the most popular that I can think of off the top of my head.
HTH.
cheers,
Rob
Rob Wells
2008-09-08 21:09:08
Only the test-coverage metrics listed here could be considered a measure of "quality." The others are measurements of complexity and readability, which really has nothing to do with quality.
Kristopher Johnson
2008-09-08 21:30:20
So are you saying that complex code isn't an indication of bad code? Same thing with excessive nesting of decision paths.
Rob Wells
2008-09-08 23:04:43
Just one other thought, doesn't just looking at the test metrics give you an idea of the quality of the assocated tests rather than the quality of the code itself?Both together give you a good metric of the code itself (the quality metrics) and the confidence in the code (the test metrics).
Rob Wells
2008-09-08 23:20:35
A:
Whenever you use a word like quality I think of the phrase "I know it when I see it." So in essence, the WTF anwser is pretty dead on. Hire better programmers and your software development quality will improve. Most metrics can be subverted by the programmers anyways, so measuring something doesn't make the end product any better.
Lost in Alabama
2008-09-08 21:23:45
+2
A:
I'm surprised no one has mentioned the Capability Maturity Model (official page: http://www.sei.cmu.edu/cmmi/) This isn't strictly a measure of software quality, but it is a measure of the quality of your development processes. The 5 levels of the model correspond to degrees of complexity / reliability of the processes, level 1 is roughly equal to "no structure, no processes" lots of CS homework probably fits the level 1 description. As you add things like version control, automation, test suites, etc. the processes move up in the levels, and a well-operated software shop should have a CMMI level of 4 (5 is not general worth the effort unless you're dealing with extremely sensitive issues, like shuttle design)
rcreswick
2008-09-08 21:37:35
CMM and CMMI are measures of the repeatability of your processes. The ability to understand a user's changing requirements and adapt to those changes is not included.CMMI is "F.W. Taylor, we can predict beforehand all contngencies and allow for them" a.k.a. Model T Ford assembly line th
Rob Wells
2008-09-08 23:01:52
A:
The first thing to remember is to define your quality terms. Unless the term quality is defined you cannot measure it.
My quality terms are based on number of bugs found against the specicifation documents. But this is an overall product quality metric not neccessarily of the development. In large projects where there are a lot of dependencies on other teams, product quality will falter. So the bugs found have to be allocated to their respective sections.
Rob Sloot
2008-09-08 22:20:25
A:
In our system we ask the users to answer a survey of 4 multiple choice questions about how they feel about the product having just used various modules.
In my experience, the parts developed with the subjective best quality code score higher.
(They can easily ignore the survey so it is not too annoying).
WW
2008-09-26 13:06:20
A:
Matrices... Doesn't tell you how good or bad your system is.
Its the users!!!
Ayreej
2009-01-07 14:13:05