ruk·si
/notes

✨ Software Quality

Updated at 2020-10-21 16:55

Software quality can be defined as the sum of:

  • Maintainability
  • Performance
  • Portability
  • Security
  • Reliability
  • Functional suitability
  • Compatibility
  • Usability

There are two sides to software quality:

  • External Quality: What the end-users experience.
  • Internal Quality: What the developers experience.

All software development is either creating a feature or removing a defect:

  • New sorting operation for table views? Feature.
  • Optimizing code? Feature.
  • Fixing a bug found in production? Defect.
  • Removing unused code? Defect.
  • Making user interface less confusing? Defect.

Less defects indicates higher quality. The number of defects tells how focused and well does the system do what user wants. Good usage experience is not a feature, it's absence of defects.

Product vision highlights defects. A defect is anything that is clearly wrong by your current product vision. Product vision and what the product should do tell what is a bug; requirements and specifications do not.

Avoiding and fixing defects is essential for any high-quality software.

  • Low defect potential: the chances of introducing a defect are low.
  • High defect removal efficiency: the average time it takes to fixing defects is low.
  • High change of noticing a defect: the faster a defect is found and fixed, the less it will cost.

To reach good internal quality:

  • You have automated testing.
  • Code is self documenting.
  • Does only what it absolutely has to. Writing code is fast, reading code is slow. And code is read multiple times more than it's written.
  • Consistent and documented architecture. Less coupling, improved cohesion, good naming, well known design patterns, framework guidelines.

Developing while writing tests is slower than developing without tests. But tests are essential for avoiding defects and reducing mental burden of developers. Research shows that full-on test driven development takes from 15% to 35% more time, but it's still worth it in the long run.

Tests allow developers to focus what you are writing, not the whole system.

Even development speed is important for quality. Speed and quality are frequently set on the opposite sides of the scale when talking about software quality; if you can do it fast, you can't do it well. But quality of built software is highly dependent on the release cycle and how fast can minimally usable version be released. This doesn't mean software should be rushed but a balance must be kept between internal quality, number of defects and how fast are new releases published to address customer needs.

- You will release more features in the same time span.
- You keep up with the ever changing requirements better.
  The features you release are less likely to be out of date when they are out.

High external quality means that you will ship faster. Then the software does what the users want so you can focus on improving the system, not reworking it by fixing defects.

High internal quality means that you will ship faster. Writing new code is easier as you know what needs to change and noticing defects is faster because of tests.

Developer discipline doesn't scale. More disciplined and professional programmers write better software, that is true. Enforcing discipline to other programmers is hard even if you write your fancy code of conducts and have your code reviews. A better approach is to force discipline with continuous integration and choosing your tools (e.g. libraries and languages) well.

Sources