When the obvious is not obvious

As a young and green manager in a large corporation many years ago, I watched dumbstruck as a senior manager spent most of his budget early in the year and came after mine - after I had carefully husbanded my resources to spend uniformly throughout the year for my team. And to my greater surprise and outrage he was given a healthy chunk of my budget – and chunks from other careful managers! We had been schooled in different schools of thought – mine to save and spend according to my means – his to grab the action wherever it lies with whatever you have. Bucking conventional wisdom he gambled his budget early in the year on long shots. He scored a few home runs and used his budget as investment capital for informed gambling – and managed his cash flow using his peer managers’ budgets.

We were driving back from a vacation trip, the other day, in the middle lane of a three lane highway. The rightmost lane was clearly marked as ending in 500 feet. While we all waited patiently for the traffic to move, several aggressive souls came barreling down in the rightmost lane and plowed their way in at the end of the merge area. The question was, does one wait patiently leaving an entire lane empty while the traffic stretched back several miles or do we use all three lanes to capacity with the consequent mayhem at the merge area but with shorter lines overall?

Architecturally, this got me thinking about conventional wisdom and the holy cows of systems engineering discipline vs. the cowboy mentality of the open road developer. And the layering and the virtualization and the platform independent designs that we all tried to produce in the days of the big three: Sybase, Oracle and DB2. As architects are we obsessed with long term elegance to the detriment of immediate benefits and are quick to dismiss short cuts as hacking? Or were we fighting all over again, the war we lost?

Today’s chaos is both a testimonial to successful, quickly developed working software that is keeping companies afloat and a tombstone for good architecture, design and documentation intentions that died on the way to a deadline. We are unable to re-engineer our way out of the mess. But how much architecture is enough architecture? How much tidiness is enough tidiness for a house to function effectively? When does architecture tidiness turn into architecture elegance and then into plain architecture obsession?

And given the mountain of legacy systems and issues, will any organization ever have enough time, money, management attention and the resources to do it over right or do we have to understand that architecture techniques have to incorporate very stringent time, resource and money tradeoffs as part of the strategy? And remodeling, refactoring, incremental evolution, and point solutions have to enter our vocabulary and our priorities.

In the building industry, architects are coming to the same realization. In manufacturing, as we burn through the earth's resources and generate ever more millions of cubic feet of carbon dioxide, we are coming to the same realization.

As the sage of Omaha reportedly remarked "Only when the tide goes out do you see all the people who are swimming naked!"