Traits and Roles

The distinction between "traits" and "roles" seems to be a popular topic in object-oriented design lately. Once you think about it, the distinction is obvious, but when you mix up the two, your programs are crap.

Being the Perl god is a role. Being a stubborn cuss is a trait. :-)
-- Larry Wall

The same distinction applies to designing companies as well. People are defined by their traits; what they do are their roles. I've been terrified in the last few days by the confusion between these two concepts: people who actually believe that your role defines who you are.

"You're in marketing now, why should I listen to you about how to design this?" WHAT?? After four years of working with you as an architect, it turns out that my architecture skills depend on my job description?

A sledgehammer is big and powerful. Someone with excellent sledgehammer skills can use that sledgehammer to great effect. But if the role is swatting flies, the sledgehammer is just not going to work. Meanwhile, even an idiot can use a flyswatter to swat flies.

Traits aren't the same as roles. Your traits very much determine your effectiveness at a role. But yeesh, changing your role doesn't change your traits! How could it?

Architecture is Strategy

Someday I hope to be immortalized for my meaningless wise-seeming quotes, in the same way as "The network is the computer" or "The medium is the message" or "The chicken is the egg."

And so I bring you: the architecture is the strategy.

At the risk of explaining myself and therefore seeming less wise and inscrutable, what I mean is: the strategy of a company is its long-term goals. With every little short-term decision, you need to be thinking of how it will move you one step toward your long-term goal. Most short-term decisions that seem beneficial won't get you where you want to go; they'll just keep you alive. The magic of a good strategy is that it takes not much more work in the short term, but you actually get somewhere in the long term.

It's the same with software architecture. Sometimes you make a decision to implement something one way instead of another because you know that you're going to be better off in the long term. "Sure, I could just use global variables for everything and would save me some time today. But none of my functions would be reusable later." But what if you have no long-term plan? If you're a consultant, for example, developing precisely whatever someone pays you develop on each contract, there's no pattern to the work, and your short term gain is your only gain. This can be profitable, but you'll never get anywhere but where you already are.

Some people refuse to think beyond the scope of their current project; some people, even beyond the scope of the current phase of their current project. Those people don't understand strategy and don't want to; they'll work for someone else's strategy, if you pay them, because they don't particularly care where they end up in the long term. People like that make good workers, but terrible architects. Because if you don't understand the strategy, you don't understand how the work you do today is torpedoing the work you'll need to do tomorrow.

This also explains why business non-strategists don't see the value of software architects. It doesn't fit into their world view. If we can do our work today, and we don't know what's coming tomorrow, what good could a different architecture do?