
What I learned building [Pulitzer winning] PolitiFact - iamelgringo
http://www.mattwaite.com/posts/2009/apr/27/key-lesson-i-learned-building-politifact-demos-not/
======
gmazzola
I've worked at a very large (60,000+ employee) company, so perhaps my
background clouds my judgment somewhat, but I think requirements documents are
quite helpful. The Software Functional Specification that was handed to me
provided a good background to the problem space.

When I wrote the Software Design Specification (100 pages, oof...), I easily
solved 2/3 of the bugs before I touched a single line of C code. I was
surprised, since I didn't think I would enjoy the documentation process, but
it really helped. I designed my module using English and pseudo-code, sent the
spec around for comments, and when the spec was approved it was a (somewhat)
simple matter of conveying a solid design into C.

Meetings still suck and should be minimized, but documentation is really
essential. I always glance at the Design Spec for a feature before going into
the code, since it gives you some solid background as to what exact problem
they were trying to solve.

------
iamcalledrob
This is essentially a very brief summary of the 37 Signals (e)book, "Getting
Real" <http://gettingreal.37signals.com/>

I suggest you all read it. They have some really, really good points and
analogies.

