Metrics on quality of software

Quality is a term loosely used in the world of software development. I would be hard pressed to mention a project in which quality of the product we we’re building was not mentioned many times over. And while clearly I work with a super team we would be hard pressed to define what quality software actually is having long settled on the I will know it when I see it camp.

Still it does make some sense to at least see what informs our decision making. So lets start

Who is responsible?

The phrase the buck stops here has as much weight in technology as anywhere else. The management believes that quality should come from the developers and the developers believe it should come from management. The truth is, both parties play a critical role in the delivery of a quality product.

    Developers: Software is highly technical, the burden of ensuring its quality rests squarely on your head, this is why you are paid.

    Managers: We developers are not good neither do we care to be good in corporate politics, your job is to enable us do our job by paving the way and then getting out of the way.

Metrics of quality

Despite the amorphous nature of quality, there are still some measures which we can use to get a rough outlook on the product you are building

  1. Reliability

Your product should do what it was built to do dependably. I have put this particular metric as first on the list because if you do not achieve this then nothing else is worth measuring.

Think about this the next time you have a two hour meeting to discuss if the logo should be placed on top of the page or at the bottom.

  1. User Experience

The end goal of all software is to serve humans. I know humans are not nearly as cool as the tech your working on, but every once in a while make sure you have some of them actually using what you are building. You may be surprised at the insights you gain.

  1. Maintainability

Most of the time we spend on software development is on the task of maintaining it. In fact almost all design principles are written with the explicit goal of making it easier to make changes to existing code base or adding new features.

  1. Efficiency

I am saddened by the number of engineers who seem to believe that optimization is yesterdays problem. To this engineers a rude shock awaits them if ever their product is mentioned in a popular outlet such as hacker news.

And even if you have the money to quickly scale up your services perhaps that money would have been better spent elsewhere/

What are some of the measure you use in your own shop? Talk to us on the comment section below


Published by


API Engineer