I was one of those weird developers who actually liked gathering requirements and writing specs, user stories, tasks, or whatever. I like doing documentation…once I’ve forced through The Right Way of Documenting things instead of big ol’ Word docs.
However, he has also been very very wealthy for a very long time, and I think that Mitch���s environment has taught him that that he does not need to be particularly clear in his instructions.
If my husband says to me, “please get me a cake”, I���m going to insist that he tell me what kind of cake, what event it is for, how many people it is for, and when it needs to be ready, and where it needs to end up. However, if my Powerful Boss says, “oh yeah, and order a cake” right before she hops in a cab to go to meet with the President, then I���ve got to figure everything out myself ��� and I have strong incentive to do so. I���ll go find my boss��� calendar, look through upcoming events on the schedule, guess at which one is likely to need a cake, and phone the boss��� cook to find out what kind of cake the boss likes. If I am really on the ball, I might phone the other participants��� people to find out if there are any food allergies, likes, or dislikes. If I am good, my boss will come back and find out that in fact she did not need to give clear instructions; if I am not good and there is no cake, I most likely would (eventually) find myself no longer employed by Powerful Boss.
Cake Requirements
Now, I have no idea how true the personal stuff there is. That’s not what resonated with me. Instead, I think the analogy of buying a cake perfectly outlines how requirements are gathered vs. how we wish they’d be gathered in software development.
People don’t want to give you detailed requirements. They don’t care, and they’ve got TPS reports to fill out. Damn the torpedos!
OK, yes, that’s an overly broad statement. The larger point is: in my experience, your work-welfare is better severed if you assume you’re buying a cake for the boss instead of complaining that you want to buy a cake for your husband.
Sure, you should be working tirelessly to convert your boss into a husband (wait…that doesn’t work…), but in the mean time to get the software out the door, you better make up for their deficiencies instead of “giving them what they asked for.”
That’s a frustrating position to find yourself in, and it’s a result of How Things Work rather than How Things Should Work. Indeed, as Joel says, it’s enough to make a body want their own office with a door they can close when they need to write up those reqruiements.
Fallacy & Paradox
Schools of thought like Agile are good anecdotes for moving you more towards the second if you’re stuck in the first. But, even The Mighty Agile can succumb to what I call Plato’s Fallacy: if you just expose the truth of the matter, people will Do the Right Thing. Indeed, as with most absurd situations that require results, like developing software in large organizations, you have to maintain a strong, operating belief in the Stockdale Paradox to deliver:
You must retain faith that you can prevail to greatness in the end, while retaining the discipline to confront the brutal facts of your current reality.
Good luck figuring out which cakes to buy. (I like German chocolate.)
Previous Topic
