Simplicity is the ultimate sophistication. –Leonardo da Vinci

I’ve been thinking about application architecture and design since I arrived at my present employer. Along with development team dynamics (a topic for another time), architecture and design have reared thier ugly heads a number of times. Being new to this team and corporate environment I have looked at apps others have built, and have spent considerable time, debugging, modifying, and otherwise maintaining several examples. The experience level here varies from newbies with a year or less of Java experience to those with a considerable number of years of experience. There is a significant level of confidence on the part of the senior staff of the correctness of the design and architecture of several of the applications I have worked seen. At first, I questioned my own knowledge and experience (I had not been a 100% fulltime Java developer prior to this) when confronted by these apps. I blamed my confusion and lack of understanding on my inexperience. However, as I talked to others and had more contact with some of these applications and the authors and architects, I came to realize that the problem wasn’t entirely my own.

Increasingly, people seem to misinterpret complexity as sophistication, which is baffling—the incomprehensible should cause suspicion rather than admiration. Possibly this trend results from a mistaken belief that using a somewhat mysterious device confers an aura of power on the user –Niklaus Wirth

I was told of the power of this application server framework, and that open source framework, and the in-house sub-framework built upon it. The ‘benefits’ hit all of the buzzwords and phrases: loose coupling, service oriented, flexibility, testability, etc.

Unfortunately, what I saw was complexity that addressed no real problem domain, or an over-engineered solution to a simple problem.
In an article by David Hayden he observed:

“In the past year, however, I have started to see various classes and interfaces being added to my code to support looser coupling. I remember the effort of creating the classes, but have not realized any benefit from their existence because their creation wasn’t based on actual requirements, but my desire to use the ever evolving best practices and patterns to make my software ‘more maintainable and flexible.’ “

In another article he goes on to define ‘low coupling’ and the downside of it:

“If a part of your application is not really unstable, don’t treat it as such. How many times have you heard a person boast about having a data access layer that is loosely coupled to the rest of the application, but which there is an unlikely chance that a different database / data access layer will be used by the application? Low coupling for the sake of lowering coupling can (but not necessarily will) cause unnecessary complexity in your application and perhaps cause more harm than good. Pick your battles wisely. “

The trend here is to apply low or loose coupling everywhere, because it’s a ‘best practice’, not because it solves a problem we actually need to solve. This trend has also led to the proliferation of ‘factory‘ classes. In the name of loose coupling, build a factory class to return an instance of an implementation of an interface. These have almost universally been one-offs with no return on the development investment. In most cases, instantiating a concete class directly would be faster, simpler, easier to understand and maintain, and most likely never change enough to require the loosely coupled version.
This article by Zed A. Shaw rings very true for me:

“This is the actions of an expert. They love complexity because the art is still new to them, something which should be explored. A list is not just a container, it’s a linked list, or red-black tree, or doubly linked list. To me, it’s just a container. I realize now that they’re missing my need for simple beautiful things. They don’t love quiet elegance, and would rather shout their superiority from the top of the mountain. Meanwhile, I’m just a lazy old man who wants to get his job done and write something without any wasted energy. I want to climb the mountain with the least amount of effort and their shouting is causing an avalanche of bad code. “

And here are some quotes that apply as well:

A charlatan makes obscure what is clear; a thinker makes clear what is obscure. –Hugh Kingsmill

Unformed people delight in the gaudy and in novelty. Cooked people delight in the ordinary. –Erik Naggum

Simplicity is prerequisite for reliability –Edsger W.Dijkstra

What have I learned? I’ve learned that my desire for simplicity in design and implementation is something to nurture, not second guess.