For a couple of projects weren't particularly big, we required this set of "specs" before release (for internal use): - Requirements specification - Design sp

For a couple of projects weren't particularly big, we required this set of "specs" before release (for internal use): - Requirements specification - Design specification - Use cases - Test plan Plus some reports. The design included a functional specification, but all of these documents evolved iteratively, so as it turned out the design document was mostly an after-the-fact record of what we did. But I don't think anyone here is an avid supporter of BDUF, so what else can a team do to prevent foolish code, other than requiring everyone to show their stuff and explain themselves regularly? If your up-front specification is comprehensive enough to prevent any bad future programming decisions, you don't need a programming team to implement it, you just need a compiler for it. Maybe that's the deep secret to "Worse is Better": bad ideas are exposed to the harsh glare of other developers early on, but it doesn't sting so bad because nobody expected perfection. Humble is better.