The last of a very good series of posts at http://feeds.feedburner.com/~r/2-speed/~3/117149909/ inspired me a little bit in how metrics and data in general should be presented.
Consider the two Churchill quotes he presents, only substitute the word “specification” (or requirements doc, etc) for “report”:
“This specification, by its very length, defends itself against being read.”
“Please be good enough to put your conclusions and recommendations on one sheet of paper in the very beginning of your specification, so I can even consider reading it”
How many of us, in our roles as developers and architects, have begun designing and even implementing a system without having even READ the entire spec? Why does an author expect somebody to read, understand, and recall thousands of “The system shall foo the bar of the blaz” statements over a period of many months? I know that I’ve typically gained my most important understandings of a system from listening to stakeholders explain WHY they want something, and from looking at powerpoint presentations that give the overview of what the system should do. I’ve long asked for “bullet point requirements” to do initial estimates and planning on. The most accurate bid I’ve made was off a very short request for quote, but we had very skilled domain experts on-hand to lay it out.
That said, what’s the value of having the spec “up front”?
Argument 1: Scope management
This is the one I hear the most… “how else do we know how big something is?” I usually counter with “How does 1500 detailed requirements tell you how big something is?”
Argument 2: It helps prevent changes/churn
Embrace it! I’ve not seen a large spec with less than 20% churn anyway.
Argument 3: The [ FDA | FAA | DOD | CMMI | DVL ] made me do it
Do they? Or is that just the default assumption from a casual reading of the process/model descriptions? Thanks David Anderson for opening our eyes to the possibility of time-shifting these needs to a JIT approach… yay for throughput. For more on this, I highly recommend reading Anderson’s blog and the Lean Software Engineering Blog, which extends many of the concepts related to Anderson’s work.