Thursday, May 5, 2011

Not Gardeners, but Diplomats

I want to respond to a recent blog from Chris Aitchison which asserts that people who design software are closer to gardeners than engineers. He's right that our discipline does not look much like engineering, but it doesn't even have the nice, pleasant predictability of gardening. And it sure is a lot less physical labor.

I used to argue that programmers are translators. This upset a lot of programmers because it meant that at least half our job is talking to humans, listening to humans, understanding humans, so that we can capture their needs in the form of software. We became programmers to deal with computers, not humans, damn it.

I no longer believe that is true. The requirements do not become software any more than one country's list of demands becomes a treaty. The final product we build is a synthesis balancing the capability of the systems we use with the needs of the users, and those needs and systems will be changing during the process of development. Even if the users and domain experts knew exactly what they needed (they don't), that would change before we finished translating those to software.

So now I'm presenting myself as a Software Diplomat. My job is to negotiate on behalf of the computer system. Yes, translation is part of the job, because I'm a bridge between two cultures that don't speak the same language. So, I translate the architecture of the available systems for the project planners. And I translate the requirements into a language the system can understand, but that is still only half of my job.

And this is worse news for the engineers who thought they had a technical role, because a diplomat's job is ALL about getting to know the needs of human beings. The requirements are simply one party's starting list of demands. The technology comes with its own list of demands.

It's incredibly hard to estimate how long it will take to broker a treaty because both sides are free to come up with new demands, hidden preconditions, or third parties with their own conditions. I try to know as much as I can about the needs of both sides to anticipate those stumbling blocks.

Users make demands for a reason. They demand things that they think will be useful. But a diplomat cannot be held hostage to one side's demands. Diplomats have a whole jargon of their own to talk about broadening the negotiation to find the best treaty. I have to find the needs that drive the users to make demands, to look past the proposed solutions and find goals.

And then I have to respond with the system's own list of demands, and I have to negotiate to meet a portion of those needs. And if you ask more of the technology, it mainly demands more money. A good software diplomat understands WHY the technology is making those demands and may be able to find another way to keep it happy.

And that's why a software diplomat will always start with the simplest offer. If we can make the software do THIS much, for THIS cost, that will be our armistice. Build one to throw away. We'll start working together and then return to the negotiating table with a firmer notion of what we really need.

When it works, you end up with software. It's an agreement between the users and the technology to work together. And, it's not always possible.

3 comments:

msluyter said...

I like your point here, but I find myself resistant to any essentialist definition of what we do. Ie, any one of "we're craftsmen/engineers/architects/gardeners/diplomats/archeologists/crack-dealers...." I think there are a lot of angles to what we do, and no one viewpoint perfectly or completely captures it.

NLJR said...

@Mike

Nothing can completely describe what we do. I'm just providing another metaphor. I think it's a cool way to highlight the importance of dynamic responses from software engineers and the people they relate to. The requirements we get aren't going to become software and we'd all be worse off if they did.

Chris said...

Nice post, I like the metaphor.