I gotta use words when I talk to you
Last week I refused to sign a requirements specification document. It caused a small stir, because the developers were sure I had to approve it before they wrote any software for me.
The meeting had been running for half an hour before one of the analysts blurted out the question she’d come to get answered. She pushed the document across the table to me and looked me in the eye. “Is it complete?” she asked, “Is it correct?”
“I’m sorry, have no idea,” I answered, and paused. The project manager eyed me thoughtfully. “We only just issued it. Perhaps you need more time to read it carefully.”
“I have no intention of reading it carefully,” I replied, “If I knew enough about mainframe interfaces to verify that this is correct and complete, I wouldn’t need you guys.”
The document described how they would meet my requirements with the resources of the mainframe system. To tell the truth, it described the design, not the requirements; there really was no point showing it to me.
But something needed to be done to address the analyst’s concern. I said, “We’ve worked together some hours on this. You know the business and what we’re up to. It looks like you’ve put a lot of work into this. The conversations we’ve had leave me with a lot of confidence that we’re going to get useful information from the interface. You should go ahead and build it.” I turned to the project manager. “That reduces but doesn’t remove uncertainty about whether this is complete or correct. That’s why we’ve planned this in two passes. We could do enough analysis to remove the uncertainty entirely in one pass. But that would tie up your system experts for weeks and months rather than days.” He paled, and showed me the title page of the document with a list of names and spaces for signatures. “I still need an approval.” I agreed to send him an email repeating what I’d said.
I spoke to him again a week later. He’d completed his list of signatures, except for mine. The list included the manager of the business unit, and his manager as well, neither of whom had any IT skills.
I wondered what it all meant. The front page looked like evidence that the signatories had approved the contents of the document. In a weak sense, that was true. No signatory objected to the work going ahead. In this sense, it was like the part in a wedding where anyone who knows any reason why it should not proceed is invited to speak up “or forever hold your peace.”
But in a strong sense, it was plainly false. Only the analysts and the programmer could do more than skim it. As communication between analyst and programmer it was fine. To the rest of us it communicated only that the analysts had done some work.
It reminded me forcibly of the times I’d seen a business manager invited to approve a thick document containing a formal description of ‘his requirements’. In my experience, the manager always signs it.
There is always something to be learned from looking carefully at such ceremonies. Why would he sign it?
Consider first his direct relationship with the document. Nobody imagines that he has been sitting up nights, reading the thing in bed. He might dip into it and find a description of some detail of the system. If it is as he expected, that will encourage him. If it’s not, he will challenge it. He might find he’s caught the team out, and if so he should send it back for review by his people, for the chances of him casually spotting an error should be small. More likely he will hear that, in order to achieve some desirable effect, the detail was done this way rather than the way he would have expected it. He doesn’t have all the details.
He doesn’t have all the details. Of course he doesn’t. Naturally, he expects his people to have been through all this. So he approves the specification, and allows his money to be spent writing software, not because he can see it describes what he wants, but because his people tell him it does. (Even the features he hasn’t thought about.)
But this just shifts the epistemological problem to his people: how do they know it describes what they want?
Here things look a bit more hopeful. They have been working with the analysts for some time. That’s exposed them to the world of systems-think. So they’ve been thinking and talking for some time about imagined systems. Doing this with analysts is different from doing it among themselves. Analysts have a vocabulary for the job. Their vocabulary allows them to identify familiar components in the requirements and to abstract from them. It also helps them to make discriminations and distinctions important to the programmers.
Working with the analysts, the business people acquire some of this vocabulary. They get some fluency in describing the imagined system. Features that are at first awkward to describe acquire familiar tags. Freed from the tyranny of detail, they are able to participate in discussions of process, more confident of the context of the conversation, of what is and isn’t assumed.
Distinguish two modes of reading: understanding (U) and analysis (A). An Arts graduate will have done most of his reading in mode U. This is how one reads novels. Mathematicians do most of their reading in mode A, toiling over individual lines of proofs.
But these are not individual Arts and Sciences modes of reading. Arts and Sciences both use both modes. A paper in experimental psychology can be read mostly in mode U, but the experimental design and the discussion of results must be read in mode A.
Some texts can be read in either mode; consider a poem or a philosophy paper. I once had a five-thousand word essay to write on three paragraphs in the Parmenides; that required mode A reading. Business people use both modes; tabulated reports must sometimes be skimmed, sometimes scrutinised.
A formal requirements specification can be read in either mode, but it can be verified only in mode A. This is the habitual mode for analysts, and the only mode for programmers. Part of the value of the document lies in its being complete in certain formal senses.
But do the business people ever read the requirement specification in mode A? Do they study it, constructing it in their minds as a mathematician constructs, examines and tests a theorem?
Not a chance.
So how can they tell their boss to approve it?
It’s the conversation. They’ve spent weeks or months in conversation with the analysts, answering questions, getting answers to their own and solving problems together. Because of this, they have confidence in their impression that the analysts understand what’s wanted, and that the document records the results of their work.
In effect, they’re telling their boss These guys now understand what we want; we should have them build it.
Notice this. Any fluency that the business people gained in the analysts’ vocabulary was a real help, possibly an indispensible help, in working with them. But it didn’t have them read the specification in mode A. That was never going to happen.
Here’s the inauthenticity stated baldly.
The development process pretends that the business people use the requirement specification to confirm that the analysts have grasped what they want. But that’s not true. The business users don’t rely on the requirement specification to tell them this.
So what do we rely on?
It’s the conversation. In long conversations about our business and the imagined system, we had the experience of being understood. That – more than anything else – tells us we can rely on their work. Without it, we’re not approving anything.
What gives us the experience of being understood? How do we know the IT people are, in Margaret Thatcher’s words, people “I can do business with”? It’s simple to say, hard to analyse: they speak our language.
Consider someone learning to speak, say, Italian. We can distinguish different levels of competence in speakers, from my toilet-and-restaurant Italian (which suffices for holidays, thank you) to the ability to speak like a native. The test for the latter is something like the Turing Test. If an Italian can’t tell Italian isn’t your first language, you speak Italian like a native. For other levels of proficiency, there are other tests, written and spoken.
A test looks like this. You get to write or speak the language in response to some question, and the examiner judges how well you use it.
In this light, most disciplines look like language acquisition. When I read for a degree in psychology I read books and went to lectures to discover how the language of psychology is used. I attended tutorials and wrote essays to practise my new language. And when I was examined, I sought confirmation that I was using the language correctly and effectively. In effect, I was joining a linguistic community, the psychologists, and the requirement for membership was their acknowledgement that I speak their language.
What can we learn, and what practices borrow, from thinking about requirement specification as language acquisition?
If I am going to pay you to write software for me, you have to speak my ‘language’ well enough for me to have confidence in your work. How do I know that you do? Not from your requirement specification document. If I spoke Italian and you German, that would be like you producing an Italian-German dictionary to demonstrate that you have learned Italian. If I don’t speak German, your dictionary doesn’t tell me anything.
No, I will judge your competence in Italian by how well you speak Italian.
So, the requirement specification doesn’t do what it’s said to do. It does document the analyst’s understanding of the requirements, but it doesn’t demonstrate to the users that he’s understood them.
If you are the business manager, and you want to reduce your uncertainty about the analyst’s work, what can you do? Informally, you can talk to the analyst and gauge for yourself how well he speaks your language. Taking him to lunch and chatting about the business might do nicely. (For the record, I like Italian food.) Informally, you can ask your people if they have the experience of being understood.
But if you wanted formal evidence that your requirement has been understood, you would not look to the specification. You would borrow a practice from language acquisition. You would set an exam.
The higher the analyst’s score, the likelier it is that he has got it right. There would be standards. A fail mark would show that he does not yet know enough about the business to specify the requirements.
If you were a project manager and wanted to assess the solidity of a requirement specification, you could do worse than set such exams for the analyst and the business user. You would set an exam on the business for the analyst (get the business people to write it) and for the business people on some of the distinctions of software specification and development – if they haven’t picked up anything about that, there’s something missing in their communication with the analyst. The product of their competency scores in each other’s language should predict the stability of the requirements specification.
It is a privilege to learn a language
a journey into the immediate
Wittgenstein has much useful to say about this. He showed in Philosophical Investigations how it is in the nature of languages that they are acquired through use not study.
The language game we are considering has two parties simultaneously learning each others’ language. What can a project manager borrow from language acquisition to improve results?
I know eight European languages with varying degrees of competence. I learned English first and know it best. Danish is probably my ‘second’ language, though I learned it fifth. I learned it in six months, while living in Copenhagen, and I learned it at KISS faster than any previous language and better than any but English. Twenty years after I left Denmark, my Danish is still usable.
The key, well-known to language learners, was immersion: practice and feedback. The teaching was divided into intensive two-week courses. Each course comprised six lessons on alternate weekdays evenings. Each lesson set enough rote-learning homework to occupy the following evening; the next lesson rehearsed, corrected and exercised what we had learned. Feedback every other day, the language spoken all about me, and more feedback every fortnight: a course not mastered had to be repeated.
Contrast this with my experience of learning Latin. I learned what Latin I know through studying it as a ‘dead’ language; there is no community of competent speakers to join, no feedback. The small Latin I know is a meagre return on five years of study.
Consider the extent to which systems analysis resembles the study of a dead language.
A project manager who knows this will arrange for business users to sit with the analysts rather than meet them from time to time. He will also arrange development in as small increments as he can manage, to provide feedback on their learning.
Extreme Programming (XP), fiercely focused on communication, makes the most radical moves in this direction, replacing formal requirement specification with always-available face-to-face communication between users and programmers. Analysis gets dropped as a distinct phase and merged into programming. Working software provides the feedback to programmers and users on how well they are understanding each other. XP relies on ‘steering’ through feedback; and the best feedback comes from delivered software.
Treating requirement specification as a Wittgensteinian language game leads you towards practice and feedback, towards XP. In my view, working code is the best evidence a business manager could ask for that his requirements are being addressed.
But if I had to ‘sign off’ a requirements document, and needed evidence of its quality, the lesson I’d draw from Wittgenstein would be to ask my people and the analysts to set each other exams to demonstrate competence in each other’s language.
Stephen Taylor 2003-07-06