On the beautiful green meadow

The aesthetic solution without a problem

Work on a perfect software solution begins on a beautiful green undeveloped meadow. It is simple and robust, it is built from modern components, uses modern concepts and design patterns, is flexible and expandable, is modular and intended as a foundation for further developments. All together, it makes it aesthetic for a software developer and software architect.

A perfect software solution? Flexible and expandable and as a foundation for further developments? A beautiful green meadow? Do I hear a CTO or software architect speak or is it an obvious euphoric attitude of a junior developer who wants to turn the world upside down full of enthusiasm? It must be one of the two, because this wish has nothing to do with reality. At least not with the reality of a company that is or wants to be successful.

Unfortunately, such views are also expressed in successful companies and it is therefore erroneously assumed that it was or is precisely this perfect solution that founded the success. In fact, this often happens, especially in large companies, and leads to downright ivory tower-like development departments, in which at some point the own solution is celebrated more than the further development is openly and result-oriented.

In my experience, it is precisely the topic of extensibility that triggers the fatal thought process: in reality, there is a conjecture, an assumption, in which direction and in what way future extension must be possible. With enormous effort, the extensibility is designed and implemented, turns out to be ballast for simple features that were previously easy to implement and the necessary extensions in the future unfortunately simply do not follow their own ideas and assumptions that led to this new foundation. In short, extensibility proves to be useless and a waste of time and investment. This failure is often so painful that it is not accepted. The extension is still being supplemented and expanded. Failure is delayed and when it finally escalates, the reason for it was by no means the basic architecture. Because what must not be, cannot be.

In practice, I have often seen this paired with the urge to always run after the latest hype, to constantly try out the latest development tools and at some point to literally design "an architecture - end in itself" that could not be surpassed in terms of software beauty and elegance, but unfortunately does not solve a single problem of a single user.

I can understand this desire and passion for my own craft. A carpenter also wants to carpenter a perfect table in his eyes, every plumber also has his own aesthetic standards and therefore an idea of what a perfect bathroom should look like. But at the end of the day, a successful product solves a real problem and not a fictitious one. A successful project implements a wish of a customer and not of the craftsman. If necessary, a successful development department leaves the cherished solution space and constructively discusses the design and implementation of the next steps together.