Windows Embedded Compact
Windows Embedded Standard
Windows Embedded Automotive
Products In Development
Cloud Services & Management
Windows Team Blog
The Windows Embedded Handheld Blog
Olivier’s Embedded Blog
The Silverlight Blog
Windows Embedded Standard Blog
The Windows Embedded Team Blog brings together a range of voices to spotlight Windows Embedded news and information and reflect the evolving world of intelligent systems and specialized devices.
Cross posted from the Windows Embedded Standard Blog.
Recently I had a conversation with a young engineer who seemed to be of the opinion that there were better things to do than waste time writing requirement specifications. I asked “Like what?” and in response I heard a list of things which included “triaging bugs.”
“Really, you think that?”
Youngsters today, where do they get these silly ideas from? Perhaps from misguided professors who are hip on all the new great software engineering advances like Agile and Extreme development. I’ve been in engineering for, well, a very long time and have seen a lot of different development processes. The one thing I can tell you, unequivocally, is that if a team doesn’t have a common vision for their deliverable, they are sunk (ask me some day about “brilliant weapons”).
That’s what a requirement specification should do.
Recently, while watching the movie The Social Network, I was amused to realize that the script contained a clear, concise definition of what the new web site would be and how it would be different than other existing web sites. It wasn’t that the script was written by an engineer with a compulsion to explain everything (a compulsion I’m sometimes accused of), but that this information was critical for the audience to know so that they could follow the story. Regardless, it could have served as a requirements specification for Facebook version 1.0.
Obviously, not all projects need the same level of detail in a requirement specification. A short pithy definition of the deliverable would prove to be insufficient as the impact of faulty product grows.
Sort of like playing “Pin the Tail on the Donkey” by yourself, but the judge of whether you put the tail in the right place is either Granny Landon or grumpy Professor Jenkins. Granny is happy if you get the tail pinned on any wall in the room and will let you grab a handful of M&M’s as a reward just for playing (I liked the brown ones because they “tasted better”). Clearly, I don’t need to spend much time worrying about where the tail should be pinned because Granny will let me peek after I’ve pinned it and I can re-pin the tail with ease.
However, since that grumpy professor might not let me graduate if I put the pin in the wrong place, I think maybe I need to be a bit more exacting and worry a bit more about the details.
So, to the agile youth of today I say, buck up and at least give me a few paragraphs so that I know what the hell you’re planning to do with that donkey tail somebody gave you. Then you can go grab a hand full of M&M’s and we’ll all go home happy.
Leave the brown ones for me.