I’ve taken the opportunity over the years to work with infrastructure teams, development teams, and even mixed teams drawn from the two IT tribes. There are some real psychological differences between infrastructure and development which I will not get into here. Instead, I’d like to propose that we can describe a lot of the differences in short, pithy statements modeled after that icon of Western kid’s television, Bob the Builder. For those of you who do not know Bob, he is a handyman who constantly asks the question “Can we build it?”. His devoted followers, consisting entirely of animated construction equipment, immediately shout back “Yes we can!”
Developers pretty much live by a modified version of Bob’s cry. “Can we solve it?” asks the naive business person, not really knowing what kind of a result he will get. “Yes we can!” respond the developers, struck immediately by visions of how to deal with whatever “it” is. This tendency is why some project managers do not leave developers alone in the room with business people; there’s no way to tell what the developer will have agreed to in the time it takes the PM to go, get a glass of water, and come back.
This laudable creed “Can we solve it! Yes we can!” stems from the fundamental nature of programming. Writing code is a puzzle game. A good developer takes fragments of information and ideas, fits them together in an elegant way, then presents a solution to some defined problem. Whether anyone actually needs the solution isn’t really in the developer’s preview.
Infrastructure and operations live in an entirely different world. They get a vast number of prefabricated components, scarce instructions, and only the most general of directions for what needs to be done. Then, when the delivery fails to meet anyone’s undefined expectations, the heavens open up and fire rains down until they frantically work out a solution to the “obvious” issues.
Unsurprisingly, the motto of most infrastructure groups could be expressed as “Make it work!” Although most are not professional engineers, they do share a lot of the same personality traits and qualities. They take what exists, figure out how it works, then make it do something the creator probably never fully intended. Stability and elegance take a second place to expediency; there’s always time to do it over but never time to do it right.
Keeping these phrases in mind helps me to understand different groups reactions as I move from organization to organization and between development management and infrastructure deployments. I know that developers will find a way to solve whatever problem we choose to present; the challenge is finding the right problem. I know infrastructure people will take whatever we give them and make it work by the date it’s required, even if they completely ignore artificial deadlines of any sort.
Frankly, the motto and the creed let me sleep at night. They also let me tailor my communications and praise to my audience, so that I deliver my message with more effect.