Good software is a contentious issue, but everyone agrees it’s important. Despite being a young programmer, I have learned a thing or two about what makes some software “good”, or rather, what makes some software bad. This article is an attempt at discussing what good software really is, and what it isn’t.
It’s easy to reduce the good of software to the economic view: the value of a piece of software is equal to the economic good it produces. But how do we ensure that the software continues to provide value, and does not get substituted by better software, or alternatively, how do we write better software?
Properties of good software:
- Provides significant value, either in the short run or the long run
The above points seem obvious, but they are essential to formulating the characteristics of good software, which follow below.
Characteristics of good software:
- Open source
- Simple (but not necessarily easy)
- Written in a suitable language
- In some cases it’s important to use an accessible language to ease contribution and review, in others it’s more important to choose a language with good compile-time verification of the program (typesystems, memory-safety, etc).
- Which language is considered suitable for what goal is a vast topic in itself, and not something I’ll discuss further in this article.
- Quality controlled
- Code review
- Well tested (unit tests, integration tests, type checking)
- Stable APIs
- If the software in question is a library or is otherwise designed to interact with other software, it needs an interface that other applications can rely on.
All software does not need all these characteristics to be good, but if it lacks several that’s probably a warning sign.
Threats to good software
- Feature creep and software bloat
- Over integration, non-modularity (the individual parts are dependent on the whole)
Philosophies on Good Software
- The Unix Haters Handbook (1994, criticism)
- The truth about Unix: the user interface is horrid by Don Norman (1981)
- The Collapse of the Unix Philosophy