There are lots of people who claim they know the best way to do things, whether it be Extreme Programming, the Rational Unified Process, Pragmatic Programming, or whatever. Every one of these groups will gladly sell you a huge pile of books to tell you how to follow their One True Way. There is a huge amount of vitriol expended discussing which Way is the Truest, and I plead guilty to having spread this disease.
I am pretty sure there is a list of things that everybody who is anywhere near decent at developing software always, always does, or pretty much everyone (themselves included) agrees always absolutely should do. I have a feeling there is widespread agreement on these practices where they are known, and a first stab at this sort of list is the Joel Test. I think that Joel's list is still somewhat opinionated and controversial, so my guess at this list follows. I'm leaving out lots of things that I think are good ideas, in the hope that in the future, I can devote all my vitriol to arguing about ideas not on this list.
- Version Control
All code, and when possible all assets (data related to the code such as artwork, "business rules", scripts, and test databases) should be managed with a version control system, such as CVS, Perforce, Bitkeeper, or Subversion. - Build Automation
It should be possible for any programmer involved with the project to produce a running copy of the software from the source code at any time. It should be possible to produce an official, "release" build of the software in order to distribute it to beta-testers or customers with little more effort.
- Test Automation
There should be a suite of automated tests run against the software after every change. When bugs are discovered, tests should be written to ensure that they do not recur. - Bug Tracker
All defects should be tracked so that they are not lost while the programmers are busy working on other things. - Development Tools
Programmers should be well-versed in the use of debuggers and profilers and should use them regularly when attempting to locate bugs or performance bottlenecks. - Human Testers
There should be a person or a department (depending on project size) responsible for testing the software, entering bugs into the bug tracker, and making sure they get fixed. In the absence of a dedicated tester (on extremely small projects) the programmer or programmers should dedicate a reasonable share of their time to integration testing.
It seems like the efforts I've read about in order to measure software quality and team quality are all fantastically complicated, expensive processes that overlook these basic issues. It seems premature to segregate your Prototype and Requirements Specifications phases if your programmers can't even use gdb (or equivalent debugger) or cvs (or equivalent version control system).
Is there something obvious I've missed, or is there some circumstance where one of these rules doesn't apply?