When you don't have a spec, everything is a bug

How many of you regularly get a detailed and complete specification document before Dev starts coding and before Test starts testing? Raise your hands, please. Anyone? Anyone? Bueller?

Heh. That's what I thought. My team takes a full month before each milestone to focus entirely on the specs for the next milestone, and even that is rarely sufficient time to get all questions answered and the spec nailed down.

If your group uses one of the agile methodologies you're probably wondering what all this fuss about specs is about. If you truly have constant contact with your customer, and your customer is an integrated part of your team, and you organize and name your tests such that they are easily read and searched and understood, then a spec is indeed not so useful and may even just be busywork. For the rest of us, though -- especially those of us delivering components or APIs to other teams, specs are necessary documents that define the features we are to plan/code/test/document/market/publicize.

When you don't have a spec, or when your spec is incomplete and/or out of date, you have several options:
 -Camp out in your program manager's office until they write it. If you have a laptop and so can get some work done while you're there, so much the better.
 -Write the spec yourself. Either your PM will thank you for helping with his workload, or he will be mad enough to finally write it himself. Either way, you have a spec to discuss with your feature team.
 -Your bug database becomes the spec. You decide how your feature should work, and you write bugs anytime it works differently. As the bug works its way through your bug resolution process, you and Dev and PM have (probably loud and heated <g/>) conversations that result in a decision whether the feature really is/ isn't supposed to work that way. Depending how good your feature team is at recording these conversations in your bug database, you have anywhere from a "No this isn't a bug" decision to a rich history full of detail.
 -Your tests are the spec. This is what Extreme Programming and various other agile methodologies are perceived to do. One difference, though, is that a team using such a methodology recognizes and highlights the fact, whereas teams that fall into doing this accidentally don't ever realize what is going on and so can't optimize their processes around the practice the way XP does. (And even XP recognizes that certain situations (e.g., writing components for use by other teams) require specs for coordination between those teams.)

In reality, of course, the situation is never so clear cut as to be firmly in just one of these camps. I have a spec for my feature, but it is nowhere near complete. On my first review of the spec I added over seventy comments questioning various areas of the spec,  several of which hit fundamental concepts behind or behavior of the feature. I pester my Program Manager on a regular basis, asking when he will have the spec updated. In between pesterings I've begun to write my test spec, identifying test cases and  determining what changes to our test infrastructure will be needed. I'm also looking at the prototype, simultaneously providing feedback to my dev and discovering the areas that are likely to be bug farms in the production code.

*** Comments, questions, feedback?  Contact me at michhu at microsoft dot com.