Requiring Specifications for Development
One consistent requirement through my years at Microsoft has been formal specification of functionality before starting code development. Like any process, it's good to ask 'is it worth it?' from time to time.
If you're a Microsoft developer who writes shipping code, you probably put together design specifications spelling out what you're going to do and why in broad, algorithmic strokes. If that passes muster, then you write functional or implementation specs which lay out your module design, interfaces, threading, and important classes and structures.
Microsoft test developers are also typically required to write specifications. They read the dev specs and any formalized requirements for the system, then write up test plans and test specs. Usually these test specs focus on what will be tested rather than outlining how the test harness will be constructed. Still, it's part of the formal process.
Requiring design specifications up front is an expensive way to develop. You're front-loading much of your design work before you have a practical feel for the problem, which can cause a number of issues. It has many benefits to offset this cost. With your module or component spelled out in black and white, other people can read it and decide if it meets their needs. Experts in related areas can evaluate the design and high-level implementation plan, and give advice on ways to improve it, or point out 'gotcha's.'
I've long felt uncertain about the value of specifications as a resource throughout the life of a product. Many times I feel like after the initial design is complete, the spec becomes a dead piece of text, which I nevertheless maintain as design evolves during implementation.
Recently I read a study from the Human Interactions in Programming team in Microsoft Research: "Software Development at Microsoft Observed." The study is short and very accessible. It describes conclusions based on a survey of more than a thousand Microsoft Developers about how they work, and delves into the value of specifications, among other things. Most of the conclusions in the paper ring true, especially when it comes to specs. Among these is that specifications are perhaps less valuable and not commonly referred to after initial design is complete.
I've tried a few projects without formally specifying them. In general I don't think they go any faster in terms of development time, though you get a certain satisfaction from coding early on rather than writing and reviews specs for a few months. However, there are definitely detractors to this 'the code is the spec' approach. First, it can be hard to know when you're actually done if you don't have a set of formalized goals and specifications: feature creep becomes even more of a danger. Second, it's easy to wind up putting together a solution which - through miscommunication - doesn't adequately meet the needs of whoever it's intended for. Third, you can wind up making some stupid mis-steps that could have been prevented by forwarding a description of what you were going to do to a few experts. Finally, the form and quality of what you get is far more dependant upon the skill and habits of the implementer than a well-specified project.
Are specifications worth doing up front? I think the answer is a pretty solid 'yes.' A better question to ask is whether the way that we approach specification and spec review is reasonable and efficient.
What do you think?
