Thursday, May 5, 2011

Diplomat, Gardener, Ninja ... Engineer

So a diplomat, gardener, and an engineer walk into a bar...

No, this isn't a joke. It's simply that time again of the year when people trot out their favorite metaphors of what software developers do. So far we've got software gardens and software diplomats. More will be along shortly, I'm sure.

I do find it somewhat remarkable (and a bit disturbing) that in 2011 it's still not really clear what it is that software engineers do all day. Many blame this "unstable" state of affairs on the youth of the discipline and its rapidly changing nature. There's some truth to this but such an explanation isn't convincing. This confusion about the job -- what it is, the best way to do it, how to evaluate it, how to improve it -- comes from somewhere. There is something, some X factor, that makes it genuinely difficult to make firm assertions about the profession and which requires so many different analogies and metaphors to describe it.

What might this X factor be? Where does the confusion come from?

At this point we can trot out the usual suspects: 'complexity' or 'communication' or 'users' or 'C++' -- my favorite -- the general notion of 'change'. What's remarkable is that each of these villains that keep software engineers up at night are tremendously complicated subjects in their own right. There are whole disciplines devoted to studying and understand each of these fields. And yet they are only part of the problem of creating quality software -- there are other factors including technology, resource allocation, testing and verification, localization and more, more, more. You might as well say it's the world itself that makes software engineering hard. The world is confusing, unpredictable, ever-changing, and full of other human beings. It's obvious that such an environment would not be conducive to any serious engineering efforts. So who can blame us for being so confused when we're dealing with such inputs?

The point, I think, is that we could spend a lot of time identifying particular sources of confusion and elaborating particular strategies to deal with such confusion. Indeed this is a very valuable exercise. Yes, users are important but technology can only do so much and so we must employ diplomatic strategies to bridge the impasse. And yes, every software development project (like every family) is dysfunctional in its own special way and we must be attuned to these highly contextual and unique aspects of each project. But these are just two of many, many strategies that we could employ to deal with the vast (and ever increasing) quantity of confusion and uncertainty that exists in our projects. Software Engineering is confusing and hard because it's literally made up of many, many confusing and hard stuff. There is no single 'problem' or 'mystery' here, there is, rather, an ecosystem where problems, confusion and complexity are constantly growing and evolving. And we have to live in it and, hopefully, live somewhat comfortably.

There are people who are specially trained to bring order and predictability to this pit of chaos. The problems they work on are 'fractally complex'; the more you dig into them and try to break down the more you find yourself confronted with new and strange problems. There are never any clear solutions and so tradeoffs must be made including tradeoffs about the tradeoffs! Because there are no formulas, no well-defined procedures, that will solve such problems these people are forced to rely on a hodgepodge of different strategies and tools including, but not limited to, science, math, duct tape, ingenuity, magic, dialogue, modelling and plain old luck to 'handle' these problems and introduce some sort of stability to people's lives. It's not so much that they eliminate complexity and risk and they certainly don't always make things 'simpler' -- it's more that they understand it, accept it, study it, deal with it, and make it a little more easy to live with it.

These people are called engineers. The name is somewhat dated but calling them 'wranglers' sounds silly and calling them 'ninja' would make it very difficult for them to get through airports. The name sort of fits: engineer comes from ingenium -- Latin, for 'cleverness'.

And yes, I'd include software engineers among their number.

No comments:

Post a Comment