Category: Softwares

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.

To be successful as an architect, you must be able to make yourself understood by people who don‘t speak your native tongue. No. I‘m not suggesting you learn Esperanto or even Klingon, but you should at least speak basic Business, and Testing. And, if you aren‘t fluent in Programmer, you should make that a top priority.

If you don‘t see the value in learning other languages, consider the following scenario. The business people want a change made to an existing system, so they call a meeting with the architect and programmers to discuss it. Unfortunately, none of the technical team speaks Business and none of the business people speak Programmer. The meeting will likely go something like this:

• A business person talks for a minute about the need for a relatively simple enhancement to an existing product, and explains how making the change will enable the sales team to increase both market and mind share.
• While the business person is still speaking, the architect starts sketching some kind of occult symbols on a notepad and enters into quiet argument with the one of the programmers in their strange multi-syllabic tongue.
• Eventually the business person finishes and looks expectantly at the architect.
• After the whispered argument completes, the architect walks to the whiteboard and begins drawing several complex diagrams that are supposed to represent multiple views of the existing system while explaining (in complex technical terms) why the requested enhancement is virtually impossible without major changes and may actually require a complete redesign/rewrite of the entire system.
• The business people (who understood little of the diagram and less of the explanation) are openly stunned and find it hard to believe that something so simple would require such massive changes. They begin to wonder if the architect is serious or just making things up to avoid making the change.
• Meanwhile, the architect and programmers are just as surprised that the business people don‘t see how the “minor” change will require major modifications to the core system functionality.

And therein lies the problem. Neither group understands how the other thinks, or what half of the words they use means. This leads to mistrust and miscommunication. It‘s a basic psychological principle that people are more comfortable with those who are similar to them as opposed to those who are different from them.

Imagine how the above scenario might change if the architect were able to explain the issues to the business folk in terms they understand and relay the business issues to the programmers in terms they understand. Instead of surprise and mistrust, the result would be agreement and approval.

I‘m not saying that learning multiple languages will cure all your problems, but it will help prevent the miscommunications and misunderstandings that lead to problems.

For those of you who decide this makes sense, I wish you success on your journey. Or, as the Klingons say, Qapla!