Monthly Archives: April 2017

An Elegant Hack

What is the ideal piece of code? An Elegant Hack.

Elegant code is clean, nicely organized code which separates all concerns, properly names everything, has methods that don’t exceed a screen of length, uses dependency injection everywhere… It can however get repetitive, bloated, and costly to maintain. A hack on the other hand is a quick and dirty solution. Something that gets the job done, but looks terrible, and maybe isn’t quite stable. However it is short and to the point.

Striking a balance between these two is the ideal. Code that can be written quickly, yet is very clean and neat. It is short, but reads like sentences of English. If anything needs changing, all concerns are neatly separated. New developers can quickly grasp what is going on and how to do things. Nothing is too complicated, or over designed. Any kind of API developed has a small surface and nudges, or even forces you into the right direction. Components are tiny and well isolated.

A thing worth considering when making design decisions is that, of the many choices available, some of them may be easily upgradeable. A simple solution might serve well in the beginning, and if it is well isolated, then a later upgrade to a more robust choice is a relatively painless process. In type-checked languages the compiler can help you quickly locate places that need changing. Using a light wrapper from the get go is maybe even better. A common complaint against using static classes and methods in C# is that they don’t allow dependency injection, thus making testing more difficult. But a static class as a facade to access a mechanism which makes sense to have globally accessible, can easily see its implementation changed, and delegated to injected dependencies. At the same time it may make the code elsewhere more readable, and its dependencies to the mechanism easily locatable. Always question the dogma! Considering such options is worth it. It combines development efficiency with following the agile principle of delaying commitment – don’t make any decisions too soon, which might limit your options in the future.

Elegance should always be the goal. As Einstein said, things should be made as simple as possible, but no simpler than that. Making code maintainable, easy to understand, change, and upgrade, is exactly the same as making code that developers will love to read. Code that is interesting, systems that don’t require much mental effort to comprehend. Never too simple, nor too complex.

The term “an elegant hack” is a contradiction, which it must be if it is to come even close to capturing the frustration involved in writing good, clean code. Finding the right design to capture the essence of the problem in an understandable and manageable way is difficult, particularly given the hectic nature of the software development process, with requirements constantly changing and deadlines always coming too soon. Developing a piece of software is a bit like conducting research. You cannot predict it fully. You discover things along the way which take you down wholly unexpected paths. Many of your assumptions turn out to be wrong, and many design decisions later cause headaches. To avoid creating a codebase that developers will complain needs to be written from scratch, remember this principle – the ideal code is an Elegant Hack.