First posted to MSDN on Apr, 01 2010
Greg Lambert, the chief tech guy over at
ChangeBase
,
responded
to my
recent blog post
on how to best leverage tools, and I believe we may have hit a bit of a bump in the road with regard to semantics. Specifically with regards to the usage of the word Quality.
I had stated:
One thing you want to be very careful of with all of the tools: it’s remarkably easy to surface all kinds of “issues” which would be “better” if you fixed them, but the software still lets you get your job done if you did nothing about it. Chances are, you were given the budget for an application compatibility project, not an application quality project. Application quality projects cost more than application compatibility projects – don’t create one accidentally.
Greg responded that improving the software quality is good, and that you probably are expected to improve the overall quality of software.
I certainly don’t want to suggest that improving the quality of software isn’t important. In fact, we believe it so important that we changed the name of the
Application Compatibility Cookbook
to the
Application Quality Cookbook
. (With the somewhat unfortunate side effect that people were then unable to find it.) I am passionate about educating everyone contributing the software ecosystem on Windows about the findings we have come across which may help them to create better software.
So, to set the record straight, allow me to clarify.
If I find an issue in software which causes the installer to take 5 seconds longer, I have a quality issue. In a 20,000 seat enterprise, that’s 27 hours wasted, at a maximum (assuming the user is staring lovingly at the screen the entire time just waiting for that software to complete the install – worst case scenario). If it takes you 27 hours and 1 second to fix it (assuming everyone’s hourly rate is identical), it’s not worth it. If it has an automated fix and requires no additional time to fix it, then of course you’re going to take that.
I once had a customer who brought me a bug he had found as part of his OS deployment testing. After I debugged it, I determined that this functionality could have never worked on any version of the operating system we had ever released. It clearly had never been executed by anyone before. And, since they had been running it for years on their current OS where it was also broken (which we demonstrated), it was obvious that this bit of functionality was something that nobody would ever use. If you spend the money to fix the bug, you do not make anybody’s life better, and you do not enable your organization to be more profitable or effective. Yet, aesthetically speaking, the quality is now better.
If you fix a bug in code that nobody runs, nobody cares. And that’s time and money better spent tackling problems that do impact your business.
So yes, please go forth and make applications of higher quality, and have them work in more business scenarios. Just don’t chase perfection as quality and improve things in ways that nobody actually cares about.
Where you choose to improve quality, do so intentionally.
