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.
