Alvin Chardon, VC++ IDE QA member here. In thinking about ways of introducing the Visual C++ culture to our customers, I’ve decided to share a story. Around 6 months ago, the Visual C++ IDE QA Team hired its newest SDET. I was excited to hear my lead wanted me to be his mentor. Having worked on the Visual C++ Team for the past 5 years has taught me that all successful projects have a well thought out plan and consistent design specification behind them. Thus, I decided to approach mentoring as I would any other project: by gathering the requirements and writing a specification – which in this case was just a training plan.
After meeting with our new SDET and getting a good grasp of what skills he needed to learn before he could execute effectively in the IDE QA team, I decided to assign him a little project. Something unrelated to our testing methodologies and technologies, but that succeeded in exposing him to C++/CLI and the IDE technologies that he will be testing. Knowing that specifications are important, I sent him a little document that specifies the assignment requirements, its purpose and what I expected the outcome to be. To summarize, I asked him to write a HelloWorld application (how original), that outputs “Hello World” in three different languages. The application was to be written in C++/CLI and to be localized using .NET’s paradigm for managed resources and satellite assemblies.
About a day later, I received email from our new hire telling me he had completed the project. I asked him to share it with me, but instead he insisted I come to his office. “All right, I will meet you there”, I said. When I arrived at his office, I was greeted with a pair of head phones and a conversation about the computer’s sound card, which to tell the truth I didn’t understand why it was important at the time. So I figure, something must be wrong with the sound card and our new SDET is only looking for some help diagnosing it. I put on the head phones, our new SDET presses CTRL + F5 and his program salutes me by saying out loud Hello World, Hola Mundo and Bonjour Monde! “You made it talk”, I said. “Why”, I asked. He responded: “Because you told me to.” Going back to my office and re-reading the specification I note:
Create a HelloWorld application, console or windows, using Visual C++ and the .NET platform to say hello world in three different languages.
“…to say hello world…” – tells you something about English not being my first language.
1. You can’t “predict” what the Visual C++ team will come up with next!
2. Design specifications need be clear, concise and specific – leave no room for interpretation.
Till next time.
PingBack from http://www.soundpages.net/computers/?p=4164
Well, I hope the SDET learnt some lessons about customer requirements too... they don't always ask for what they want, and it's important to establish the underling problems driving their requirements instead of simply meeting their specification.
It's certainly a cute story, but it reminds me of the Microsoft "You're in a helicopter" joke...
"tells you something about English not being my first language"
Your use of the word "say" was correct idiomatic English. A computer pedant can pick on it the way the SDET did, but then you can ask about the word "print", which is correct idiomatic compuglish for "output" or "display"... except for "sprintf" which doesn't print or output or display.
Now if one of the SDET's favourite fields was computerized speech, or if they'd been working on it recently, or if their fluency in English or compuglish is lower than yours, then the misunderstanding is understandable. Otherwise they were being a pedant or a joker.
Of course it's different when we're talking to computers or documenting how to talk to computers. Then we'd better say what each word really does. Though of course our talking or saying can be accomplished by printing or displaying.
'it reminds me of the Microsoft "You're in a helicopter" joke...'
That's the IBM "You're in a helicopter" joke. The joke is older than Microsoft.
I remember once I requested a business analyst to insert the rules of email address validation into the functional design specification and the response I got was "I think this should be a well-known thing that not required to be stated down."
English is my second language too. But I never doubted about what you meant before I read that you had to put on head phones because you wrote 'say'.
The newbie must be a joker because that 'say' meant print. And this print means outputs to display device. :)
Given the context of this story, "say" could be taken as synonymous to "print", "put" or "output". But, since VS enables developers to generate speech from text, I think it was perfectly acceptable for the developer to Interpret "say" as: generate audible speech.
I think this story also provides an interesting example of what happens when the person who writes the requirements is not the person who writes the code. While this is pretty typical in larger projects, it does illustrate the potential communication disconnect that increases in relation to the number of people on the project.
I say "say", you say "c'est", he says "生", she calls the whole thing "off".
I think the story has a broader lesson - that we should never implement blindly exactly what we are asked. If there is possible ambiguity in the specification, we should ask for a clarification, ideally from the specification's author. Mentor should teach mentee that this is an example of when you should re-state the requirement and say "is this what you mean to ask for?"
If the pedant arises, then out-pedant him. A program playing back a sound file is not "saying" anything - there are no lips to flap or vocal chords vibrating. The speech is not generated from the text, or from the concept behind the text.