A Crash Course in Software Quality

It occurred to me recently that while intuitively obvious to many the concept of “Software Quality” is probably something never actually studied by the average developer who doesn’t have a formal computer science education.

Yet understanding software quality beyond intuition has been extremely helpful to me over the years as a programmer and software architect. And while there are many amazing self-taught developers it’d be a shame for me not to blog about it since I can cover the essence of software quality so quickly.

A Bit of Personal History

It was back around 1988 I was first learning OOP, also known as “object-oriented programming”. One of the few books avaiable on the subject was “Object-Oriented Software Construction” by Bertrand Meyer, but of the books available I probably learned more from it than any other. I’ve learned an amazing amount since but it was from that book I learned many of the foundational principles I still use daily as a software architect.

I still think most of what was covered in the book’s 2nd edition is relevant. If you are interested in reviewing it to decide if you want to read it I found a copy online but you can buy a used one for US$0.01 on Amazon.com

The External Factors of Software Quality, Named

The first chapter in OOSC covers Software Quality. To explain the concept Meyer simply defined numerous related terms, which he called “External Factors”, and wrote a few paragraphs about each. I’ve edited his definitions slightly, for brevity, and I’ve included them here as your crash course in software quality. Enjoy!

  • CorrectnessThe ability of software to perform its exact tasks, as defined by its specification.
  • RobustnessThe ability of software to react appropriately to abnormal conditions.
  • ExtendibilityThe ease of adapting software to changes of specification.
  • ReusabilityThe ability of software elements to be used to construct different applications.
  • CompatibilityThe ease of combining software elements with others.
  • EfficiencyTo place as few demands as possible on processor, memory and bandwidth.
  • PortabilityThe ease of transferring software to different computing environments.
  • Ease of useThe ease with which various people can learn to use software to solve problems.
  • FunctionalityThe extent of possibilities provided by a system.
  • TimelinessThe ability for software to be usable when or before its users need it.
  • VerifiabilityThe ability to detect failures and to trace errors during operation.
  • Integrity – The ability of software to protect code and data from unauthorized access/modification._
  • RepairabilityThe ability to facilitate the repair of defects.
  • EconomyThe ability of a system to be completed on or below budget.

Take these terms and commit them to memory. And when building software ask yourself “How does my software fare with respect to these factors?” If you can answer that your software fares well then you can rest easy in knowing that you are probably a developer who builds quality software.

As a side-note, after having learned OOP in the late 80’s I’m still surprised when a professional WordPress developer says, in 2014, that “I don’t really understand OOP.” Time to get with the program, I say!

4 Replies to “A Crash Course in Software Quality”

  1. The first book I used to learn some programming was for the commodore 64. I’m starting to think that maybe wasn’t the best starting point:) It was a lot of fun at the time though.

    I honestly don’t know what it truly means to fully understand OOP, but I’ve warmed up to it in the last year.

  2. I have read this book and this is infact provides lot of useful things regarding quality software in OOP but it never seemed easy to me. OOPs implementation is very challenging in getting software quality.

  3. I also enjoyed leinsting to your presentation Peter. As a web developer with limited Flash experience, it was an excellent introduction to ActionScript 3.0, while immediately seeing examples of practical and creative usage of the language. Now I have to find the time to read your book :-)

  4. Having concrete ways to measure the quality of code helps us determine what improvements we can make as developers. On your recommendation, Mike, I am picking up the Bertrand Meyer book.

Leave a Reply

Your email address will not be published.