Programming

Code Complete 2 – Steve McConnell – The Software-Quality Landscape

I just love Steve McConnell’s classic book Code Complete 2, and I recommend it to everyone in the Software ‘world’ who’s willing to progress and sharpen his skills.

Other blog posts in this series:

⚠️ Users care about whether the software is easy to use, not about whether it’s easy for you to modify. They care about whether the software works correctly, not about whether the code is readable or well structured.

⚠️ The General Principle of Software Quality is that improving quality reduces development costs. Understanding this principle depends on understanding a key observation: the best way to improve productivity and quality is to reduce the time spent reworking code.

Characteristics of Software Quality

The software has both external and internal quality characteristics. External characteristics are characteristics that a user of the software product is aware of, including the following:

  • Correctness
    • The degree to which a system is free from faults in its specification, design, and implementation
  • Usability
    • The ease with which users can learn and use a system
  • Efficiency
    • Minimal use of system resources, including memory and execution time
  • Reliability
    • The ability of a system to perform its required functions under stated conditions whenever required – having a long mean time between failures
  • Integrity
    • The degree to which a system prevents unauthorized or improper access to its programs and its data. The idea of integrity includes restricting unauthorized user accesses as well as ensuring that data is accessed properly
  • Adaptability
    • The extent to which a system can be used, without modification, in applications or environments other than those for which it was specifically designed
  • Accuracy
    • The degree to which a system, as built, is free from error, especially with respect to quantitative outputs. Accuracy differs from correctness; it is a determination of how well a system does the job it’s built for rather than whether it was built correctly
  • Robustness
    • The degree to which a system continues to function in the presence of invalid inputs or stressful environmental conditions

Programmers care about the internal characteristics of the software as well as the external ones. So here is a list of internal quality characteristics:

  • Maintainability
    • The ease with which you can modify a software system to change or add capabilities, improve performance, or correct defects
  • Flexibility
    • The extent to which you can modify a system for uses or environments other than those for which it was specifically designed
  • Portability
    • The ease with which you can modify a system to operate in an environment different from that for which it was specifically designed
  • Reusability
    • The extent to which and the ease with which you can use parts of a system in other systems
  • Readability
    • The ease with which you can read and understand the source code of a system, especially at the detailed-statement level
  • Testability
    • The degree to which you can unit-test and system-test a system; the degree to which you can verify that the system meets its requirements
  • Understandability
    • The ease with which you can comprehend a system at both the system-organizational and detailed-statement levels. Understandability has to do with the coherence of the system at a more general level than readability does

The attempt to maximize certain characteristics inevitably conflicts with the attempt to maximize others. Finding an optimal solution from a set of competing objectives is one activity that makes software development a true engineering discipline. But then again, that doesn’t mean that there has to be a tradeoff with another characteristic. Sometimes one hurts another, sometimes one helps another, and sometimes one neither hurts nor helps another. For example, focusing on adaptability helps robustness and vice versa.

Techniques for Improving Software Quality

Although it might seem that the best way to develop a high-quality product would be to focus on the product itself, in software quality assurance you also need to focus on the software development process. Here are a few tips for improving software-quality:

  • Setting explicit quality goals
  • Making the quality assurance activity explicit makes the priority clear, and the programmers will respond by focusing more on quality rather than how quickly they “complete” their programs
  • Developing a testing strategy
  • Informal technical reviews
  • Formal technical reviews

Relative Effectiveness of Quality Techniques

The various quality-assurance practices don’t all have the same effectiveness. Here are some quality-assurance practices:

  • Informal design reviews
  • Formal design inspections
  • Informal code reviews
  • Formal code inspections
  • Modeling or prototyping
  • Unit tests
  • Personal des-checking of code

Percentage of Defects Detected

Used on their own, the techniques detect on the average only about 40% of the errors. The strong implication is that if project developers are striving for a higher defect-detection rate, they need to use a combination of techniques. A study by Glenford Myers shows that using any combination of techniques increased the total number of defects found by a factor of almost 2.

Cost of Finding and Fixing Defects

Most studies have found that inspections are cheaper than testing. A study at the Software Engineering Laboratory found that code reading detected about 80% more faults per hour than testing. Another organization found that it cost six times as much to detect design defects by using testing as by using inspections.

As it was mentioned in previous chapters about design, the longer a defect remains in the system, the more expensive it becomes to remove. So a technique that catches the error earlier reduces the cost of fixing it. Even more important is whether the technique detects the symptoms and causes of defects in one step, e.g. inspections, or like testing, finds symptoms but require additional work to diagnose and fix the root cause.

The bottom line is that for a quality program you must use a combination of techniques, here’s my recommendation:

  • Formal inspections of all requirements, all architecture, and designs for critical parts of the system
  • Modeling or prototyping
  • Code reading or inspections
  • Execution testing

The general Principle of Software Quality

The General Principle of Software Quality is that improving quality reduces development costs. Understanding this principle depends on understanding a key observation: the best way to improve productivity and quality is to reduce the time spent reworking code.

The industry average productivity for a software product is about 10 to 50 of lines of delivered code per person per day (including all noncoding overhead). Part of the reason for these seemingly low productivity figures is that industry average numbers like these factor nonprogrammer time into the lines-of-code-per-day figure. But the single biggest activity on most projects is debugging and correcting code that doesn’t work properly.

The study at IBM produced similar findings:

Software projects with the lowest levels of defects had the shortest development schedules and the highest development productivity. Software defect removal is actually the most expensive and time-consuming form of work for software.

Keynote that you should take from this chapter is that quality is free, in the end, but it requires a reallocation of resources so that defects are prevented cheaply instead of fixed expensively ?

Written by Nikola Brežnjak