What metrics to calculate if writing specification is worth its time?

Question

What metrics to use and how to make calculations if writing specification for a new programming project is worth doing it and spending time (and money)?

Answer 1

In general small, straightforward, non-critical project: no specs. Large, complex, critical project: definitely specs.

There perhaps cannot be any cut-and-dried metrics here. You'll have to rely on your software engineering judgment.

Answer 2

In general, you should always write out specifications. You should need to be convinced not to.

• If you have more than one person on a project, you'll definitely need specifications.
• If a single person project will take more than a week, you'll probably need specifications.
• If there has ever been confusion or communication difficulties between you and your client, then signed specifications are a must.

Answer 3

Focus on essence and what's most important to your customer. The overall business goals and visions. I like the "elevator test" - to be able to explain what your product does in under two minutes:

for (target customer)
who (statement of need or opportunity)
the (product name) is a (product category)
that (key benefit, compelling reason to buy)
unlike (primary competitive alternative)
our product (statement of primary differentiation)

(from Geoffrey Moore's book Crossing the Chasm)

Perhaps this doesn't answer your question, but writing such a small "specification" could be done for any project.

Answer 4

I think you'll find yourself backed into an uncomfortable corner if you try to use any metric to definitively predict or control the outcome of your project. Ultimately, your project sponsor/owner will ask the questions "how long/how much" ? The best you can do is a forecast that is based on your current knowledge of the project at this point in time - and this just comes from experience and literally guess-timating.

And here's the catch: Your estimates will likely be off by several orders of magnitude. They only become more accurate as your team understands the problem domain and they estimate no more than 2-4 weeks ahead, max. Barry Boehm (and Steve McConnell) illustrated this effect with the "cone of uncertainty" principle:

The further you are from implementation of a system or feature (left side), the greater the innacuracy of your estimates (-0.25x - 4x). As you get closer, and understand the problem domain more, estimates begin to take on greater accuracy (0.8x - 1.0x). This is why, in software projects where there is a lot of "noise", or "complexity" (ie. almost every project) we want to leave concrete estimation until the last responsible moment - no more than 2-4 weeks out.

You can also expect one thing with absolute certainty: The specifications WILL change over time. How you plan to adapt and manage that change will measure your success.

So, the best judgement that can be made to scope your work would be to assemble the team who will work on the project and the "customer" to collaboratively work out the big brush strokes - the major features of the project. Write these as user stories that the team estimates using relative weight points (see Mike Cohn's book on Agile Estimating and Planning) and devise a release plan that will give the customer a "draft" forecast on what to expect - they can then decide if the investment will generate the return they are looking for.

Of course, I'm assuming that you'll be releasing early/often so that your customer is always in possession of some functional increment of the final product - vital for their continued valuation of the project.