16 January 2013

Software Quality - Can we improve it

Software Quality is something that everybody wants to be good. So what is good? And if it’s not good, how do we reach to that point? And if it is good, can it be any better?
Let’s start with some basics about software quality.


Software quality can be described as: how well we meet some requirements. It is often related to a business value. Is the customer satisfied with the product the paid for?
Customers are often people and what satisfies him will differ, therefore requirements for the product are well defined. The result is some form of minimum quality for the product that both the customer is satisfied with and the product developer can fulfill.

Requirements can be divided in two parts:
  • functional requirements 
  • non-functional requirements
Functional requirements refer to the specification, the requirements the customer and product developer has agreed to. They well defined. They can be measured and verified. If the quality is bad, the product developer won’t get paid.

Non-functional requirements refer to quality that is not directly visible to the customer, like maintainability and efficiency. Compared to functional requirements, these are “soft”. These are often results from architectural decisions and developers coding practices. Measurement of these requirements can be difficult and needs to put in context to give a meaningful value. 

What is good?

Back to the second question, what is good? Maybe it’s easier to define the opposite. If something is good, it can also be “non-good”. We can call it bad. If the quality is bad, it does not behave as we are expecting. The requirements are not fulfill. The customer is not satisfied.
If the requirements instead are fulfill, then the customer should be satisfied of the quality. We can then define that if we meet the quality for something we have agreed on then it is good! 

Let’s stop!

What about non-functional requirements? What if the code
  • has extremely long source code files
  • has functions that are pages long
  • is really hard to understand
  • only a part of it are covered with tests
  • is so tight coupled that even dynamite won’t separate it
  • needs extremely much memory and cpu
Can the customer be satisfied even if the internal structure is a mess?

Yes it can!

The solution can be to use more hardware or increase the development time with a factor X. It won’t be cheep but the customer will be satisfied. 

Or maybe there is another solution... 

If it’s not good, how do we reach to that point?

For functional requirements it’s easier to reach good quality because they have been agreed on with the customer. They are on paper. They can be measured. 
Non-functional requirements are more trickier because the limit for “good” is something we state our self. We don’t agree with the customer who the product shall look inside. It more about how much work are we willing to put down for a product?

If it's good, can it be any better?

I just claimed that the customer can be satisfied and the functional requirements are fulfill, even if the internal structure is a mess. He will probably not be overwhelmed. The good parts will weight more than the bad parts, as specified in the requirements.
But what if the internal structure (code) would be
  • easy to understand
  • easy to change
  • easy to test
  • cpu and memory efficient
It sounds nice. It sounds even better than good! No extra hardware needed. The development time is probably much lover. It open ups possibilities to change the requirements earlier in the development cycle if the customer is not satisfied. The staff are probably also happier because its more easier and more “fun” to work with the product. In the end the customer will be more than satisfied.

Can we improve it?

Back to the end question, software quality - can we improve it?

Yes we can! 

By having good quality on the internal structure the product cost will decrease and improvements of the functional requirements are easier to implement.


  1. Hmm, there is a third kind of requirement that makes this somewhat harder:
    The unspoken functional ones.

    There is a lot of functionality a customer expects that will never be part of any spec, could be a smart, responsive interface, bugs fixed that impacts foundation/legacy, conformity or general performance/compatibility issues.

    Also curious about the measurements you are talking about, how do you measure functional quality? Much of quality is not objective in my view but subjective. For instance, how do you compare the quality of two GUIs our searchresults, if they were measurable they should be easy to compare right? But people (different end users) will have different opinions and you don't know those (so you can't simply generalize) and it most likely changes over time?

    Final measurement question: How do you find measurements on quality that are actually measurements, meaning, a change in the model used to measure must always indicate an equal change in the product?

    Overall I think it's very interesting and I think you touch something really important but I'm a but skeptic about your simple models of requirements/specification, measurements and quality... Not necessarily a hinder to your conclusions though.

    Would love to discuss it (back on Tuesday, Jan 29th .) and great job!

    Nice to see your blog is up by the way! Looking forward to what's coming!

    1. Hi Erik,

      Thanks for your feedback! I will answer some of your questions now, the rest (and I supose you have some more :-) ) will be answer in next and following posts.

      First of all, I agree with you that quality is hard to generalize and define, because we make it very personal (which is right in some sense). But you know what, I do it anyway, because it makes it easier to reason about.

      To your questions:

      Unspoken questions:

      Smart, responsive, performance are quite unclear words, but there exists mental spec inside the customer, if we are talking about a existing (or competitor) on the market. Some of the don't have to be specified, if they are not fulfilled, your out of business. If its something completely new, the customer doesn't has "any" expectations.

      Measure functional requirements:

      Some requirements are easy to measure, for instance: The airbag should work when you hit another car with force X. But with internet search results and response time for popup menus, a incremental release to the customer, so the feedback can be used to "improve" the functional requirements. The first release should only consist of mimimal functionality.

      Change in model:

      I'll get back on this one.

      I hope you have got the answers you wanted, else we can have a chat the 29th.
      Hopefully I will have the next post up in the beginning of next week and I will continue with how can we improve the software quality.
      // Pierre