
Always write a spec - nreece
http://blogs.msdn.com/ericlippert/archive/2009/11/19/always-write-a-spec-part-one.aspx
======
run4yourlives
It's this type of thinking though that has lead to some of the most over-
engineered pieces of crap ever built.

Point being: The person writing the spec isn't the one - 99% of the time -
that will be using the software. At the very best - if you are the main user -
you're not exactly sure _how_ you will use the software, since it doesn't
exist yet; ergo, the spec is always going to be wrong.

That's okay if you can keep the spec small and nimble. At that point thought
it's just a recording of a thought process. Of course such small iterations
are better realized by just writing the code outright, testing for intended
functionality and releasing into to wilderness to test whether your assertions
about the use of the code are correct. (i.e. testing the spec itself)

The faster you can get to that last point, the better you can use your time.
In many cases (not all) the act of writing the spec only lengthens the entire
process.

~~~
nreece
Spot on. User Stories (Agile) are a much better tool for managing
requirements.

------
mahmud
s/spec/unit-tests/g

