It seems like a strange idea – that people can build things that are so complex that they no longer understand them fully. It is more common in the realm of large projects where thousands of people work together on a single goal (think of the Space Shuttle, with its millions of moving parts), but it also happens on occasion in software development.

I can think of a handful of projects that I have worked on that have reached this point. One in particular, although the number of lines of code is not exceptionally large, has so many moving parts that it is actually impossible to determine in advance what effect any given change will have on its operation. Modifying its core functionality becomes a delicate game of trial and error.

A lot has been written in recent years about simplicity: the slow food movement, the advantages of simple film plots, or the longing in some quarters for smaller government. Perhaps we live in a complex age, and this is merely a reaction, a desire for a world that is understandable. Perhaps in a more bucolic age, people long for complexity.

This thought occurred to me recently while pondering chess – why are piece swaps so common? By exchanging two equal pieces, the players reduce the number of options open to them in the future, and (unless part of a larger plan), both players come out of the swap without additional advantage. From a psychological perspective, why would players do this? Perhaps the reason lies in simplicity itself: by reducing the number of pieces on the board, and hence the number of possible moves, both players gain the advantage of a better understanding of potential outcomes.

Returning to software, I’m reminded of projects where the goal is to integrate a large number of third-party components. As I always explain to the customer, when you build something that works with three external parts, it isn’t just one and a half times as complex as communicating with two. Rather it is an order of magnitude more complicated. Add another outside component, and you increase the complexity by a further order of magnitude, and so on. At some point the complexity introduces a significant amount of risk to the project; in my experience these are often projects that are doomed to failure from the outset.

Perhaps it is no surprise that the most successful software (and hardware) projects have been those that simplify complexity, that square the circle by providing an understandable interface for a complex morass of components. The dashboard of a SaaS (software as a service) product, conveying massive amounts of information in a few simple graphs, or the clean, chunky graphics of the Web 2.0 movement. The user interface of an Apple product, shielding the user from the messy internal operations that make it run (and sometimes driving power-users to distraction), or the classic hidden front panel of the consumer electronic gizmo.

The lesson for the developer is thus: perhaps it isn’t possible always to Keep It Simple, Stupid – but it should always be a goal to keep it as simple as possible. And where simplicity is not feasible, to ensure that the interface is as streamlined as it can be.