Radical simplicity

In March 1947, President Harry S. Truman addressed Congress and delivered what ultimately became known as the Truman Doctrine, stating that the United States would support “free peoples who are resisting subjugation by armed minorities or outside pressures.” Back then, the outside pressure was communism, and although the United States supported anti-communist movements all over the world, the Truman Doctrine was more important as a philosophical line in the sand.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

In the world of IT, the outside pressure we battle is complexity, and the "cold wars" in IT have essentially been between the pernicious agents of unneeded complexity and the freedom fighters of simplicity.

The simplicity freedom fighters regularly raise their clenched fists on blogs and mailing lists, but the cause has never been crystallized in a dramatic, Trumanesque way -- until now. In a sweeping blog post last week, Adam Bosworth outlined a recent talk he gave, which he humbly summarized as “a reminder to a group of very smart people that their intelligence should be used to accommodate really simple user and programmer models, not to build complex ones.” Humility aside, Bosworth’s blog post is a rallying cry for IT and the technology industry to fight for simplicity. Say hello to the Bosworth Doctrine.

Bosworth’s talk was rich and wide-ranging, with effortless references to everything from the fall of the Soviet Union to T.E. Lawrence’s Seven Pillars of Wisdom. But the core of the Bosworth Doctrine is that good software takes our very humanity into account, whereas software that might be elegant to computer scientists suffers an ugly fate: “That software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel-cored, able to survive and grow while that software which is demanding, abstract, rich but systematized, turns out to collapse in on itself in a slow and grim implosion.”

From search and user interface to programming and data exchange, simple solutions might not win in a technical purity contest, but when real work gets done in a reasonable but slightly messy way, who cares? At the very least, simpler solutions drive broad adoption of new technology that the hand-wringing agents of complexity rush to “fix.” Just look at the hordes of technologists continuing to adopt quick-and-dirty XML instead of HTTP to do actual work now, while the reams of clean-but-slow WS standards are worked out.

Too often, when IT focuses on “getting things done,” far too much emphasis falls on the tools used, with a quickly diminishing emphasis on the things themselves. Architecture discussions can spiral into needless complexity as rapidly as engineers can scribble boxes on a whiteboard. When developers fall in love with the technical mechanics of solving a problem, they risk forgetting the problem itself, and by extension, the people they are ostensibly serving by solving the problem. Abstractions are important, but people don’t actually live and work in whiteboard drawings.

The forces of unnecessary complexity needn’t crush the will of simplicity advocates, but it takes constant vigilance. As individual technologists, we might not have the clout of Truman or Bosworth, but our daily, microcosmic decisions create the larger technology environment in which we all operate. It’s a daily battle, and if we uphold the Bosworth Doctrine as we make even the smallest IT decisions, keeping things simple is within our grasp.