Principles for programming beautiful code
Can programming code ever be considered a beautiful endeavour? Is the act of programming alone enough to incite such a description? We take a look at who thinks what in this never-ending debate.
Have you heard about Hate Driven Development? While not an official term, Rafe Colburn has characterised Hate Driven Development (HDD) as “when you come to hate working on something so much that it inspires a surge of productivity that leads to completion”.
HDD is thus promoting productivity – but of course, it’s not fulfilling. Ideally, a developer wants to find exciting jobs that make it possible to intelligently solve issues with ‘nice’ code.
However, what constitutes the ‘beauty’ of code is not an easy thing to grasp. Everyone has probably heard the phrase: “But this is a beautiful piece of software!”. But what is it about this software that demands descriptions akin to ‘beauty’? Does a consistent set of coding principles even exist that can describe the ‘beauty’ of code?
Principles for “beautiful” code
While hard to define or quantify, Ole Lensmar attempts to describe some of these principles:
- Integrity: Beautiful software solves one problem better than others – you can wholly and exclusively leave it be without it getting seduced by potential enhanced functionality. “It sticks to its ways”. Integrity also applies to its interaction with the user: it remains a consistent user interface with no surprises. Whether classed as harsh simplicity or sweet playfulness, the main thing, the ‘pitch’, will be maintained throughout the software.
- Usability: Beautiful software takes the novice by the hand and leads them to their goal. Constantly striving to prevent the misuse of features, nice code tries to anticipate the needs of the user and give them the right advice. It’s simple enough for newbies plus affords advanced users the opportunity to realise the full potential of the software.
- Innovation: Beautiful software does not shy away from finding new ways to solve a problem. If an interaction had you previously rummaging through nested menu structures, then suddenly just says “click”, it’ll suddenly have you feeling like, “How did I get along without this feature?” You begin to re-think a problem domain. Innovative solutions open our eyes and allow us to recognise new opportunities, as well as risks.
Short is beautiful
An even simpler denominator is suggested by Johanna Rothman, who says that the beauty of software lies with the brevity and conciseness of its communication: Short is beautiful! This declaration also includes the development process itself. In an Agile mindset, this would also mean the adoption of short stories, short iterations and short feadback cycles. You could even add the KISS principle, which translates to: “Keep It Simple, Stupid”.
Alternatively, we have the following interpretations as well:
- Keep it simple, stupid.
- Keep it short and simple
- Keep it simple and smart
- Keep it simple and straightforward
- Keep it safe and sound
- Keep it sweet and simple
- Keep it small and simple
- Keep it simple and safe
- Keep it safe and simple
- Keep it strictly simple
- Keep it speckless and sane
- Keep it sober and significant
Can code be “nice”?
The beauty principles outlined above don’t satisfy us entirely yet, but they’re taking us closer to what might constitute the beauty of code. Or are we headed along the wrong track? Jeff Atwood of Coding Horror thinks that the concept of beauty shouldn’t really be applied to programming code. Ideas can be beautiful, algorithms can be beautiful – programming code itself is not:
The beauty of code lies in the architecture, the ideas, the grander algorithms and strategies that code represents.
And in fact, the upper principles don’t necessarily refer to the appearance of the code, but what causes this code and what it stands for. As a side note, the beauty principles above are not attached to any particular programming language.
On the other hand, we all know the horror that comes over us when we take a look at software and see its horrible source code. So if ugly code exists, there must be nice code too, right?
What is the most ‘beautiful’ piece of software that you’ve written? And what rules or guidelines did you follow to attain this ‘beauty’?