IT Quality - A Question of Discipline(s)!

People tend to talk a lot about software quality, but what is it exactly? Sure, there are a number of tools that promise to measure your software's quality level. Some of them are certainly quite good at helping you visualize their results. Sonar for example, is a tool that combines multiple matrixes to make up a quality index. The output is a value from 1 to 100%. This is great because we are all quite number oriented in software. We get that a quality index of 5% means the software sucks and that 100% means it's the best piece of software ever.

But what is this quality index saying exactly? Isn't software more than just a bunch of classes and countless lines of code? Shouldn't we be looking at the whole software lifecycle to determine the quality of our output?

Sometimes it seems like software developers are on their own little island, happily isolated from everything… But looking only at a quality index is just like putting your head in the sand. Developing high quality software requires so much more than just excellent code… It's also about the ability to extract the "true requirements", it's about some deep and far-reaching functional test cases and it's about a swift and flexible deployment process… These things are all integral parts of the build. And in the end, each step/discipline is equally important in determining the quality of your software.

A project showing a 100% quality index score can still be given a no-go by testers, requirements engineers or accepters… My point is, quality indexes are great for developers to monitor the quality of the code, but true software quality can only be achieved with a great team of passionate, dedicated people, truly collaborating in an efficient and transparent way. Also, quality should be measured along the entire software development cycle so every step/discipline is held accountable for their output.

In my next blog I will address why transparency helps out to be more efficient.