The Craftsman's Advantage

What a presumptuous name for a blog.

No, it isn't an attempt at solidarity with people who sweat for a living. And "Architect" is just the term HR departments reach for when they run out of lofty prefixes for "Engineer" -- a title that doesn't seem to bother some very distinguished individuals at (say) Sun and IBM.

With "Architect" too often comes the mandate that Thou Shalt Stop Coding, having at last risen above the mass of mere craftsmen. I still get asked, "You write code? Aren't you a [title deleted] of Architecture?" And the look that suggests I am indulging some unsavory juvenile pursuit, like zapping ants with a magnifying glass. (Actually, I used a chemistry set. Higher kill ratio.)

Code is the fundamental tool of our trade, and there's much to be said for attaining, and retaining, the status of craftsman (or craftsperson, if you're that P-C.) Which explains the "blue-collar" bit. It comes from a project post-mortem some years ago, at which I had the good fortune to be consulting, rather than sitting in the stocks.

Among other things, we found a distressing lack of technical leaders with practical knowledge, people who could think strategically, communicate with senior management, run teams, and still keep their hands dirty -- that is, maintain key technical skills that would allow them to know, not just believe, whether a project would succeed. "Craftsmen. Blue-collar types," someone said. Another: "Yeah, blue-collar architects!" Grins all around.

Good term for it, I thought, and filed it away, to soon forget in the frenzy of week-to-week.

It came to mind again when my wife and I were having renovations done. Adam and Bob (not their real names), our architect and builder, had long since, er, moved up the ladder from individual contributor, but I was struck by how completely in touch they were with "real work." As I watched them in action on site visits, and eavesdropped on abstruse chatter about soffits, cantilevers, load-bearing beams and whatnot, I realized the difficult relationship we see between developers and architecture astronauts was not there.

The reason? Adam and Bob weren't guessing. The project didn't have a "probability of success." Their blueprints and plans were as solid as the concrete foundation they had poured the last fall. They knew how to build the addition on our house, could see every step in their heads and even do it themselves if they chose, because they had done it before. And as their trade advanced over the years, with new tools and materials and techniques replacing the old, they had kept up.

That same commitment to craftsmanship creates a different sort of software architect as well. Being able to design and build confers a more nuanced, more credible perspective on

• When REST is appropriate and when WS-* is needed
• When to cross the line from Ruby on Rails to JEE or .NET -- and which to choose
• When SOA is a wise investment and when it is a waste of time and money
• Where caching should go in your daringly innovative N-tier solution, to keep it from sucking mud
• Whether your outsourcing partner is writing quality code or creating maintenance headaches
  
• When to take a calculated risk on an alternate persistence approach
• Where that shiny new middleware the vendor is pitching fits in your messaging infrastructure
  
• When a box-and-arrow diagram is geek line art, and when it has a workable implementation behind it
• Whether a sharp job candidate is just talking a good game, or can actually get things done
• When to add new languages and platforms to your app development strategy, and when to take them out

The non-craftsman is at a disadvantage because every technology is a black box. Its behaviors can only be understood from the outside. Its capabilities are conceptual, scrutinized perhaps but never experienced firsthand, with the immediacy and intimacy of actual practice. Its limitations, if not readily apparent, are a latent and immeasurable risk.

Maslow wrote, words to the effect: "When the only tool you have is a hammer, you tend to see every problem as a nail."

For software architecture, I would add: "When you've never actually used a hammer, you can't tell if a problem is really a nail."

(Disclaimer: The above opinions are mine alone and do not necessarily represent the views of current or former employers.)