I lost track of which blog I found this by (read it on my Zaurus travelling to the office) but there's an interesting article on the development of the software that powers the space shuttle. Its sounds kinda boring work too with all those specifications but its hard to argue with the quality and massively-bug free code.
I think the modern equivalent of 40,000 page specifications is lots of test cases that demonstrate what the software should do; document requirements through test code. There's an interesting part in the article where the software team is divided into two teams
- coders who write the code
- testers who try and break the code
And there's a healthy competition between the two. If the test cases are written in software this could amount to one team of people writing test cases to try break the code and another team trying to write bullet proof code to get past the test cases.
I think both teams could learn alot from each other. In particular the testers should really be developers who know how to develop unit and integration testing software. Far too often in the software world testing teams are viewed as people who 'push buttons' rather than people who develop test cases to automatically test software.
I wonder if it'd help if software teams took turns being in both camps? Say 2 weeks a month they spend purely writing test cases to try break a part of the system, the next 2 weeks they spend writing code on another part of the system to try get past the test cases put in place by the other team. This could lead to some healhy competition.