Maya on Interaction

…when you can squeek by with software engineers alone

Because understanding a problem and implementing an information system to to solve it are not the same thing. As AntonyWasserman puts it in an IEEE software article, “the cognitive leap from understanding a problem to implementing a system is enormous.” “Writing code isn�t the problem”, argues Bill Curtis, in a Communications of the ACM article, “understanding the problem is the problem.”

The move from understanding to implementing can be full of expensive guesswork and technical bias (when ‘the ultimate’ platform for the project is the one developed by the software engineer’s dog’s startup). Information systems analysts are forced, by their mandate, to go through the trouble of disguising their guesses and biases in the language of customer requirements. Is that slimy? Who knows - but it’s worth doing because it promotes integrity.

Even if ulterior motives sneak into a technical decision (that dog really is charming), going through the exercise of justifying that decision has a purificatory effect. And this is just the sort of excersize you should expect from your information systems lady.

A good IS analyst should consider it her business to know:

1. The nerve-wrecking mess of problems that a company handles. She should know this business as if it were her own - because it is.
2. The expertise and sensibilities of the people who handle these problems. She should know what it’s like to solve problems in their shoes, at thier offices, on their train-rides, in their bathtubs, see what they see on their screens, hear their phones ringing and witness the flood of emails that they cope with as they do their work.
3. Every significant or quasi-significant bit of technology news that adds to her mental store - and her company’s knowledge base - of features and functions that support problem-solving in her clients’ domain.

Think of all this knowledge that an information systems lady has, and ask yourself: is it really possible to derive a program from requirements? Not likely - at least not cheaply. Because requirements are so much more complex than what you can write, and because they change all the time, the specs are bound to be ambiguous. This means that a system under construction is vulnerable to the whims of its programmers. Programmers intuition can be a fantastic resource - but not if programmers are utterly blind to the reality of software use. So how do you fight programmer blindness to context of use: Hire an information systems lady.