He suggests these 2 questions as the main business considerations when it comes to software quality:
- Does the software do what it’s supposed to do?
- Can I easily change what the software does?
In other words: Software quality is determined by both outcome and continuity (the extent to which software allows for changing circumstances, see Jeff Sussna’s book Designing Delivery for more information on this matter)
The second question ultimately – and perhaps counterintuitively – is more important than the first: If a software can’t be changed easily bugs will pile up and the cost for implementing new features will explode.
A codebase that’s amenable to change typically is characterised by high cohesion and low coupling of components and code entities. In Erik’s words:
- Cohesion answers the question, “do things that belong together actually appear together?”
- Coupling answers the question, “do things that don’t belong together appear together?”
The article therefore can be summarised in this quote:
High quality means high cohesion and relatively low coupling. Codebases exhibiting these properties lend themselves to easy change.