Fifteen years ago this month a piece of mine appeared in EXE Magazine (RIP) lamenting unnecessary complexity in software. A significant update for the twenty-first century proves to be unnecessary. The message and the examples are the same, so I'm posting it again for posterity, as caution for the next fifteen years, and for the sake of simplicity.

Uncertainty is normally seen as something you must either suppress or avoid. Of this many people appear, well, certain. That you should embrace it and use it to help determine schedule and design is not immediately obvious.

Generality and reusability sound like such good qualities to have in code that is easy to forget not only how hard they are to achieve, but also that without the more modest qualities of simplicity and utility how little value they may hold.

Abstraction is a question of less over more. But is it also a question of high over low? It turns out that the common way of describing abstractions in terms of high-level and low-level hides a number of assumptions, some of which suggest that we often look at abstraction the wrong way up (or down).

What can you learn from testing? When you look beyond the red and the green, the fail and the pass, you can learn a lot more about the nature of the code and the nature of the problem domain. And there is a lot to learn — software development is called knowledge work for a reason.

There is a subtle but useful distinction between code and software. Programmers write code: a formal plan of the software, expressing its intent in maximal detail. Software is the end product: in execution it is what the user perceives, interacts with and experiences. Sometimes this difference can be significant.

Be careful not to confuse the map with the territory. Presentation and representation are different concepts for different purposes. The everyday notation for many quantities, such as money or time of day, is not necessarily a good indicator of how they should best be represented in a program.

We were in the pub when Charles posed an NP-hard problem: "How do you teach programmers style and elegance in code? I would like five points or properties that I can teach to my programmers." Trusty pints of Guinness in hand, Charles, Frank and I set about trying to find some kind of answer.