Elegance is a refined quality of gracefulness and good taste. An elegant solution to a problem is defined by an ingenious simplicity and neatness. Elegance demands an unusual effectiveness, and allows for complexity to be illustrated in a beautiful and fascinating way.
We should all strive for elegance in our code. Elegance is what allows clear communication of a solution, no matter how complex the problem may be.
Utterly expressive code conveys its intent explicitly, and facilitates an ease of acceptance for new features or changes to existing behaviors. In this way, illustrative code becomes the documentation of itself, eliminating the need for other artifacts to crack the code into more readable terms.
Haphazardly writing code, without a struggle for elegance, breeds endless cycles of sloppiness, “hacks,” maintenance nightmares, and confusing pieces to an endless puzzle.
Are you familiar with the broken window effect? The idea was first published in March of 1982 inside The Atlantic Monthly entitled, “Broken Windows,” by James Q. Wilson and George L. Kelling. An excerpt reads as follows:
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters light fires inside. Or consider a sidewalk. Some litter accumulates. Soon, more litter accumulates. Eventually, people start leaving bags of trash from take-out restaurants there or break into cars.
The broken window effect was used to cleanup the great city of New York in the 1990’s. Code can also have “broken windows” in the form of haphazardness, sloppiness, incompleteness, and hacks.
These broken windows can be fixed in an effort to strive toward elegance. The more the struggle toward elegance is cultivated, the easier maintenance becomes and new features are accepted with simplicity.
Bad architectural design of software that cannot be changed forces those who strive for elegance to bang their head against a wall repeatedly. Architectural changes are not cheap, and often perpetuate their cost as time goes by.
A bad architecture is like having a three-legged mule. The cost of hacking a solution up in order to ride on top of the three-legged mule will eventually compound until the mule trips and everything it was carrying crashes down with it.
Exceptional architectural design should be fanatically sought after by the people able to change it. Designers ought to be the masters of elegance; without an elegant design, the code which supports it is truly doomed.
Developers often misunderstand elegance and reduce its meaning to simplicity alone. Simplicity by itself is in no way elegant. Simplicity is not bad, but complete simplicity in a complex system is not possible; the complexities simply cannot be made simple. Elegance is required in these situations.
For example, a toaster is a simple contraption. You put an item in the slot, push the button down, and in a few minutes your toasted wishes come true. Functionally, this is a simple procedure.
However, attractive looking kitchens demand attractive looking toasters. A functional, beautiful toaster requires a bit of elegance:
A functional, inelegant toaster
A functional, beautiful, simple toaster
How can we be elegant developers? Unfortunately, there is no simple answer; elegance is not a design pattern. Usage of the proper design patterns in the proper place, and at the proper time, can positively affect the elegance of code.
Conversely, overuse or misuse of design patterns can quickly destroy any existent elegance. A continuous study of architectural design, code design, and experience while keeping elegance in mind will produce a great developer.
Therefore, the greatest developers can express complex ideas in a superior and fascinating way, explicitly communicate intent, and produce code that is surprisingly easy to read and maintain.
For further study, I would recommend reading Eric Evans’ Domain Driven Design. Eric is one of the most eloquent expressive writers I have ever read, and I am sure his code reads the same way. I would also recommend Robert C. Martin's Clean Code, as he is one of the most outspoken legends on the matter.
|Domain-Driven Design||Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)|