The problem is not the problem

When someone starts to tell you about something that they need to get done, already you are thinking about how they can solve the problem. You are thinking about technology and all the things you can do with it; they are thinking about the task that they need to perform.

Actually, they really aren’t thinking about that. They are thinking about what they need to do to get a pay rise; they want to get a promotion; they want to improve the performance of their team so that their team doesn’t get taken over. So with all these things in mind, is it any wonder that they can’t turn out a decent spec, or a decent set of requirements; they can’t even answer questions like “what do you want it to do?”. They do know what they want it to do: they want it to get their boss fired so they can get their job; they want it to get their kid a dog; they want it to enable them to leave on time.

As my old metalwork (*) teacher used to say, first define the problem. The real issue here is getting people to tell you what they already know, then capturing it in a structured way that you can turn into a list of the nouns and verbs of the system; and while you are at if, figure out where the gaps are. And you have to do this in a language that you can both understand and you have to do it while carrying on a normal conversation.

Mostly, people fall into two groups; those who think that computers are amazing things made of spells and spiderwebs that can do anything and the people who program them are able to get the computer to do anything. The other group is still in the dark ages of desk calculators and any time the application does anything they want it to spit out everything that is related and not do anything until it has a good few clicks to encourage it; they are the ones who always want another “are you sure?” dialog box.  There is more than a grain of truth in both camps, so be gentle with them.

Actually, the real, real problem is getting them to engage with you at all. The real problem is making them see that if you don’t know what you want, you definitely won’t get it. The problem is, as all interesting problems are, a people business. Getting people to tell you what they want and then explaining that they can’t have that, but they can have this other really interesting thing that they didn’t even know that computers could do is all part of the fun. Actually, it is all part of the fun working on any kind of agile team. I pity the poor suckers whose only contact with the client is the bug reports that are fired at them by level 2 support (and they don’t even get to see level 2 support, they don’t even get an email from them; they just get a bug feed).

As with all people problems, there is no no simple solution and rarely is there some sort of break point where it all becomes clear. With people problems it’s uphill both ways and the wind is in your face. We should be grateful that all we need to do is get people to talk about what they want out of their computer systems and not what they want out of life. Anyone who is a real manager – or even better an HR manager – knows that is the real secret sauce of a productive organization.

In any case, the problem is not the problem; the problem is getting people to realise that unless they face their problems and take responsibility for the solution instead of handing it over the IT butler to sort out, then they won’t get what they really want.

* – Actually, he wasn’t my metalwork teacher; by the time I was doing it, the subject was called Design & Technology. He was a rather odd chap was Mr Tooze. He preferred to sharpen his pencils with a piece of sandpaper and then wipe it on his sock; oh and it isn’t called sandpaper it’s glasspaper; and he had a tic in his face tha made him look like he was blinking; and he spread his glue using carpet cutoffs that he kept for the purpose. And whenever he heard car tires screeching he would always say “I know that driver is under 21 years old” and then proceed to tell a story about how he had been the first on the scene of an accident where a motorcycle had hit a sportscar head on; the motorcycle had cut the car in half and the irst par of the motorcyclist he found was his foot.

2 thoughts on “The problem is not the problem”

  1. I was actually going for something a little more than that.

    Yes, DDD encourages the developer to work with the language of the users and model the problem in those terms but I was thinking more fundamentally than that. If IT is important, then don’t expect some nerd to do it right for you; stand up and take responsibility.

    The converse is also true; if we in software development want users to take responsibility for the software being correct and good, the users must also have the power. The power to decide how software is built and when they are happy with it; as they do in architecture.

    And that, of course, brings with it a whole set of other problems; like passengers deciding that they want to fly the plane. Or deciding that even though they have been flying the plane up until now, they really are quite busy right now and they are just going for a quick nap and could we keep and eye on it… We need to take care of our part as well, and not let the current business language and process make the design of the software a simple “port” of the wetware to a digital process.

    Like I say, this is a people business and there are no simple solutions for this; like the agile manifesto says, face-to-face conversation is the only way.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s