Category: Softwares

We build tools. The systems that we make have no other reason to exist (nor we to get paid) than to help someone, usually someone else, do something.

Martin Heidegger, an influential German philosopher of the 20th Century, explored the ways that people experience tools (and more generally “equipment”) in their lives. People use tools to work towards a goal and the tool is merely a means to an end.

During successful use a tool is zuhanden (“ready-to-hand”, having the property of “handiness”). The tool is experienced directly, it is used without consideration, without theorisation. We grasp the tool and use it to move towards our goal. In use, it vanishes! The tool becomes an extension of the user’s body and is not experienced in its own right. One sign of a tool being zuhanden is that it becomes invisible, unfelt, insignificant.

Consider what it feels like to hammer a nail or to write with a pen. Think about that immediacy. Think about the way the tool seems to be a seamless extension of your body.

Alternatively, and usually when something has gone wrong with it, the user may experience a tool as vorhanden (“present-at-hand”). The tool is isolated from the goal, it lies before us demanding attention. It becomes a topic of investigation in its own right. The user is no longer able to proceed towards their goal but must deal first with the tool, without it doing anything to move them towards their goal. As technologists we tend to experience the systems we build for users as vorhanden while we build them, and again when we receive defect reports. For us, the tool is quite properly an object of enquiry, of theorising, of investigation. It is a thing to be studied.

However, it is crucial to their success that the users experience the tools we build for them as zuhanden. Are your systems architected to be invisible in use? Does the user interface fall naturally to hand? Or do your systems keep demanding attention, distracting users from their goal?

General intelligence, resourcefulness, thoughtfulness, a breadth and depth of knowledge, and an affinity for precision are laudable qualities in anyone, particularly prized in architects.

Cleverness, however, carries a certain additional connotation. It implies an ability to quickly conceive of a solution that may get you out of a jam, but that ultimately rests on a gimmick, a shell game, or a switcharoo. We remember clever debaters from high school–always able to play semantics or work the logical fallacies to win the point.

Clever software is expensive, hard to maintain, and brittle. Don’t be clever. Be as dumb as you possibly can and still create the appropriate design. The appropriate design will never be clever. If cleverness appears absolutely required, the problem is incorrectly framed; reset the problem. Reframe it until you can be dumb again. Work in rough chalk sketches; stay general. Let go of the flavor of the day. It takes a smart architect to be dumb.

It is our cleverness that allows us to trick software into working. Don’t be the attorney who gets your software off on a technicality. We are not Rube Goldberg. We are not MacGyver, ever-ready to pull some complicated design out of our hats having been allowed only a paper clip, a firecracker, and a piece of chewing gum. Empty your head and approach the problem without your extensive knowledge of closures and generics and how to manipulate object graduation in the heap. Sometimes of course, such stuff is exactly what we need. But less often than we might think.

More developers can implement and maintain dumb solutions. In dumb solutions, each component can only do one thing. They will take less time to create, and less time to change later. They inherit optimizations from the building blocks you’re using. They emerge from the page as a living process, and you can feel their elegance and simplicity. Clever designs will stay stubbornly rooted; their details are too embroiled in the overall picture. They crumble if you touch them.