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?
Posts
10 comments:
I don't think debuggers are that universally valued; Liskov and Guttag's classic Abstraction and Specification in Program Development argues mostly against them, for one.
Tools for collaborative design, information sharing, and collaborative organization -- wikis, UML (ick), use case sharing. Projects frequently misuse bug trackers for this.
Comparing with the Joel test, you have probably missed some human resources best practices. (I resist the urge to scare quote, see!)
I can only think of "don'ts" though, like: don't sign a contract specifying a hard delivery date without at least vaguely discussing it with at least one person connected with your development team.
I don't know how to reformat that into the kinds of formulations you're using above, but "code cannot be written infinitely fast by burned out zombies" has got to be uncontroversial enough to make the 'beyond dispute list'. You'd think.
Functional requirements should be defined in some form. With some approaches the tests may serve this purpose, but however it's done it's best to agree on when to stop coding, before you begin.
That might be more of a single-programmer best practice, and it's sort of implied in #3, but I think it's something important to keep explicitly in mind. Otherwise, it's easy to be on a coding binge, write a bunch of new stuff, then have no idea what's wrong when it doesn't work. (Or is rejected by your automated test suite, or whatever.) As I recall, Glyph, it was you who reminded me of this way back in the day during CG at Smith. :)
IMHO, writing software doesn't really benefit from a debugger, unless you don't understand the environment you're working in; in that case, a debugger (well, preferably; or at least a REPL) is almost indispensable for examination and experimentation.
In general, I find debuggers extremely valuable for learning about software I don't understand. Of course, I can use them as crutches to write software I don't understand, and that's bad. However, as long as I sometimes have to learn about software I don't understand, debuggers will remain indispensable. For example:
- diagnosing and fixing a crash in third-party software
- characterizing the behavior of a Win32 call
- as a substitute for a REPL in e.g. C or Perl
Yeah, as I write this, I'm about to start a debugger on some code I wrote today and yesterday to figure out why the test is failing in an apparently inexplicable fashion. :)
I would like to say something more about this, but I'm not sure that anyone agrees on what form (or how detailed) these requirements should be. I know there is a lot of disagreement from one end of the spectrum to the other. The XP folks seem to believe the specs should basically be re-written every week or two, and that artifacts describing it outside the code should never be preserved: various other SE disciplines seem to believe in writing a whole prose book describing a project before writing the first line of code.
You're right. I've had a number of very bizarre questions from other folks lately, the answer to all of which has been "Why don't you just test each change you made and see which one was the problem"?
This seems like such a basic problem-solving skill that I'm wondering why it even needs to be on this list, though...
What pieces of information, in particular, do you think are universally agreed upon have to be tracked? RT does support sharing "use cases" as tickets, as well as customer support issues, bugs, features, and other, similar things...
Post a Comment