I attended a session by one of our senior managers. He defines Software quality metrics as 2 things.
- Did we deliver what was required?
- Was it 0 defect software?
If the answer to both these questions is "Yes" then that according to him is a good quality software. Now that is a bare minimum required for every software company in the world. And that is what is expected as a bare minimum in Microsoft. But even if we achieve that much, it would be given good credit and would be a huge target achieved. For the simple reason that every software gets old. And it is not feasible to write new software every time we need an upgrade or new features. Even at Microsoft we face "Legacy Code" issues.
But that's not the point of discussion here. These two quality metrics cover a lot of other things; like the first point itself covers Performance, Usabilty, Capability, Reliability, Stability, Scalability. And the second point covers issues like the application performing the way a user wants it to. So it could be a soft bug, like not a bug according to specifications document, but the user just thought the application would behave in a different way. So technically this is a good definition about quality metrics.
But there are some other metrics which I think I should mention here. I am not trying to say that My Senior Manager has missed out on these points, Just elaborating on what he might not been able to say in the session, considering the time constraint or perhaps respecting the intelligence of all engineers present (assuming they already know). "Considering all the other factors to be constant", like the laws of economics (law of demand, supply, etc) More things need to be considered. Let me elaborate.
I divide software quality into 3 main constants
- Product Quality
- Process Quality
- Maintenance Quality
Product Quality: This basically covers what is mentioned above. But a couple of more things. Like how quickly can we change the software? Extend it, Expand its scope? If there is a lot of hard work and if the application is resilient to change, then that's perhaps a foul smell. I understand the "Legacy Code" constraint and other real world issues; and hence I mentioned, "considering all the other factors to be constant" meaning in a utopian scenario.
Process Quality: When I say process, I am basically talking about profitability. How can we write high quality code while we maintain profits? The process / system should be able to take up most of the production responsibilities. Not only there should be minimal redundant code, there should also be minimal redundant effort. Automation / Re-use / Smart tools are the key to building a good process. I am not talking about the Microsoft MSF, CMM, RUP or any such processes. I am just talking about a process that makes software development quick. Quicker delivery results in more profitability.
Maintenance Quality: How can we build software so that removing / replacing / adding a component / feature is not a nightmare? How can we improve maintainability? This is something that cannot be found in any functional or non functional requirement document. This again increases the profitability of the company and elaborating this would be an insult to the reader's intelligence.
Now the question is, all this is true in the utopian scenario, how can we get into the real world? Well we (Microsoft) are already doing an amazing job on that. We are evangelizing the Individual Contributor stream as much as possible, We need more architects. More people who can design, review code and really foster quality work.
The old adage holds true here in software engineering more than anywhere else. "Knowledge is Power".
