The anime “Violet Evergarden” contains a sequence of scenes that indirectly illustrates problems in software development and similar fields, and especially where requirements are concerned:
I write from memory and might have the exact details wrong. The principle should be clear, however.
For simplicity, I will only speak in terms of customers and users below, and with little differentiation, even when discussing software. In reality, the situation can be quite complex with, firstly, a typically clear differentiation between customer and user, and, secondly, various different stakeholders, decision makers, intermediaries, whatnot, that influence the result, do not necessarily speak with one voice or share priorities, and sometimes do more harm than good. (Note, in particular, the “Chinese Whispers” effect and how too many chefs can ruin the proverbial soup.)
Violet is a beginning writer of letters for others in a partially illiterate society. In an early task, she is supposed to put the feelings of a young woman into words. This young woman speaks of a suitor, using slightly derogatory formulations, seems cool and disinterested, and has a general take of “he has to step up his game to prove himself worthy”. A letter is written and sent—and soon the young woman returns in wrath, because her suitor has severed ties.
This was caused by a combination of at least four problems:
Violet had been much too literal in her formulations and had brought too much of the customer’s words over, without properly cushioning and paraphrasing them in a manner that matched the seeming purpose—to get the suitor to step up his game. The result was that the “cool and disinterested” attitude of the young lady and her slightly derogatory take on him came across. No wonder that he lost interest.
The work of Violet and her colleagues went beyond taking dictation, putting formal messages into the appropriate language, whatnot, and contained a more interpretative aspect of expressing the feelings of the customers. In this, they might have differed from historical scribes, let alone the stereotypical secretary-taking-dictation in older movies.
The point when faced with the stated needs of a customer (software user, whatnot) is to produce what is actually wanted. This can take considerable interaction and clarification, and requires a non-naive interpretation. Often, it is also wise to point out flaws in an idea, suggest alternatives, etc., be it in the interest of clarification or to help a user with too limited knowledge of what is and is not possible, costly, wise, whatnot, make a better decision.
From circumstances, it is clear that the letter was not read to the young lady before it was sent, to verify that intent and implementation actually matched. If it had been, the problem would almost certainly have been detected before the sending and revisions would have been possible. (If in doubt, had the customer signed off on the latter as-it-was, then Violet would at least have had a stronger position to defend her work.)
Ditto software—and with more complex tasks, it is increasingly important to continually make comparisons between what the customer wants and what has been developed/is currently in development. This the more so, when seeing an interim product can lead to a change in preferred result. (Scrum and other agile methods often have a deliberate focus on such comparisons and adaptions, while more traditional processes can be hard to combine with this type of thinking.)
Likewise, it is clear from circumstances that none of the other colleagues had read the letter, because it did not only obviously (in the eyes of someone more proficient—or, even, less like Data of “Star Trek”) miss the intended result but was also quite amateurish and not something that a seasoned professional would have accepted without considerable revisions.
Ditto in software: Even in normal cases, some type of peer review and other types of quality checks are of great benefit, while giving a raw beginner unsupervised work and then failing to review the result is to flirt with disaster.
The customer had not at all said what she wanted to say (or, at a minimum, should have said): Upon her return, the young lady suddenly spoke of being in love with the suitor and positively wanting his courtship, while being deeply distraught over the apparent end of their relationship. The closest that she came to the statements of her previous appearance was something along the lines of “women wanting to be pursued”, and how she had tried to cause such pursuit by seeming cool and disinterested (and so on). What, then, she originally should have said is exactly that: I love him and I want him to pursue me. (Or whatever variation might apply, e.g. “[...] pursue me harder.”.) Without the right words, it would have taken a mind reader to get the right result—not just someone more experienced and proficient than Violet.
Conceivably, someone sufficiently used to reading between the lines, to deciphering female communication errors, and to seeing poor female approaches to romance would have been more successful: At least in fiction, this type of error has precedence, as with Klara in “The Shop Around the Corner”, while e.g. the infamous help-women-get-married book “The Rules” explicitly pushes a somewhat similar idea.
However, if a customer were to rely on such massive re-interpretation, she would engage in a very dangerous game—and the letter writers would do so, if they attempted it: Another scene (likely, from a little earlier) showed a customer flying off the handle and refusing payment because another writer had used overly reconciliatory formulations in a letter of complaint that (in the eyes of the customer) made it seem as if he, the customer, had been to blame. (The episode did not contain enough information for me to judge whether he was right with regard to the letter and/or the original complaint. This, especially, as the right answer to the former might differ between a more Western and a more Japanese communication style. However, note that an apparent acceptance of blame does not only affect how positively or negatively a letter of complaint will be received, or whether the complainer will be satisfied by “venting”, but also e.g. later chances to press the matter in court.)
Ditto in software: If the customer does not make clear what he actually wants, he cannot expect to get what he wants. This partially overlaps with the responsibility of the service provider to investigate requirements more deeply, but it is far from impossible that a customer deliberately misleads, e.g. by not acknowledging a budget limit or a lack of proficiency with computers that he might see as embarrassing or, to stick with the Japanese, as a loss of face. Ditto, he might speak honestly but while honestly making an incorrect estimate of his budget or his own abilities. If in doubt, it would be foolish to rely on others to dig deep enough, instead of just volunteering what one wants.
This is the worse, when the distance between the eventual developer and the end user is large. I have, for instance, often seen requirements documents written by product managers who do not understand what makes sense to the end user (because they are not him) and do not understand what software can and should do (because their own user experiences with other software is limited to the likes of MS Office and because they have no clue of what goes on “under the hood” of any software). In such situations, there might be no-one who simultaneously has the competence, the willingness, and the opportunity to straighten out any cases of poor communication from customer and/or end user.
The aforementioned “The Shop Around the Corner” provides a different type of illustration of how easy misunderstandings can arise:
I checked the Wikipedia page for how to write “Klara”, and also noted the mention of a song, “Ochi Chërnye” (apparently, Russian for “Dark Eyes”). I have seen this movie on at least half a dozen occasions, spread over some forty years—and I could have sworn, based on repeated mentions by name in the movie, that the song was called “Old Teutonia”. Presumably, my expectation of an English name made me re-interpret what otherwise might have sounded like gibberish into something that fit an English pattern. (This, maybe, the more so, because the film plays in Hungary, which long had a strong, if not necessarily voluntary, connection with Austria and the German-speaking, “Teutonic”, world, and which I do not associate as strongly with Russia.)
Many misunderstandings can be avoided merely by putting something into writing or, more generally, using several types of communication to bring something over.
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.