What do I mean by elegance? Most software engineers equate elegance to efficiency. Still some equate elegance to robustness. Others choose correctness. All are variables in the equation of elegance. Many other variables exist and all are important.

Make no mistake, software is art. Some artists prefer oil on canvas as their medium. Others choose water color. As software design engineers (SDEs), we have chosen 1s and 0s to communicate our creative visions. Elegance must exist at each step in the engineering process and not only as an afterthought in the development phase. Elegance is the responsibility of each and every participant with accountability functioning as the enforcement point. Without accountability, chaos reigns. Accountability starts within.

Many software engineers find themselves searching for or memorizing patterns that “work” to shortly find themselves bulimically spewing the results onto their canvas. What happened to the elegance of originality? It’s far too easy to become a GP (“Google programmer”). Why? Because creativity and originality aren’t as convenient as letting others do the work, which leads to chaos and hard-to-maintain code; especially, when you’re not the original developer.

Stay with me; we’re only scratching the surface. Do you remember the last time you really evaluated the usability of your consumer API surface? Did your evaluation begin in the design phase? Start with a high-level view of the scenarios. Then oscillate between architectural design and the scenario-based consumer API surface. Do not think about technical design until you’re satisfied with the consumer API surface and the architectural design. Keep in mind; it’s certainly acceptable to refactor your architectural design and consumer API based on the technical design.

An apparent and even larger obstacle I’ve noticed lately is the inability for an SDE to make the jump from procedure (function)-oriented design concepts to that of object-oriented design while keeping an eye to efficiency in terms computational complexity and network round-trips. The devil is in the details. In my opinion, one can’t be an effective architect without being an even more effective SDE; period. The implementation details do change the architecture.

In general, people tend to migrate toward what makes them feel good. Rework doesn’t feel good; no one enjoys it. But, if that was true—if you truly don’t enjoy rework—then why would you not elegantly architect, design, and develop your code initially? Why do you make more work for yourself? Elegance as a foundational element is difficult. More often than not, SDEs take the easy way out because they equate efficiency to speed of completion. I’m not advocating “analysis paralysis” but instead a balanced design. Deadlines must be met. Deadlines should not be met at the expense of elegance.

It’s your canvas.