The name of the company that makes the ticket tracker we use at divmod (RT, from Best Practical) inspired me to think about best practices today. It surprises me that the software industry doesn't really seem to have a consensus about best practices.

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.

1. 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.
   
2. 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.
   
   
3. 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.
   
4. Bug Tracker
   
   All defects should be tracked so that they are not lost while the programmers are busy working on other things.
   
5. 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.
   
6. 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?

I just had a look at the PyCon Schedule, and I'm impressed. It looks like the organizers have done an awesome job yet again. I plan to attend as many talks as I can this year.

I've just spent an exhausting all-nighter working on a particularly galling feature of our soon-to-be released product but I wanted to get this out before taking a nap, since I've been composing it in bits and snatches for days.

Since I'm now syndicated on Planet Twisted, I suppose I had better say the occasional relevant thing.

In addition to my main presentation (on the Divmod-developed technology, ATOP) I've got some ideas for either lightning talks or open-space sessions (depending on level of interest) I might do in dull moments at PyCon. Does anyone want to hear one of these?

1. The Long Hard Road to Zope
   
   An exploration, with heavy audience participation, of why everybody writing sufficiently complicated code in Python ends up rewriting every major aspect of Zope one at a time (object database, component model, asynchronous networking base, thread pool, web templating language, not necessarily in that order) but Zope itself is difficult to use and so routinely critcized by the community despite also being widely loved and touted as an example of Python's power. I'd love it if this could include some feedback from the Zope folks about how Zope can be integrated into these ad-hoc environments when you "really need the whole thing", how to tell when you really need the whole thing and when a partial solution might be more appropriate.



2. Disassembling Twisted
   
   I want to break Twisted into lots of different pieces. Currently there is a huge amount of coupling between packages: if someone makes a problematic, compatibility-breaking change in CVS head, it doesn't matter if that change is in a horribly obscure place, it blocks a whole release, bumps a major version number and prevents all packages from being released until it can be tested on all platforms, fixed, stabilized, etc. I believe that the Python core has similar problems (and possibly more ideas for solutions) with its increasingly sprawling standard library and extremely slow major-version release cycle. On the other hand, neither the Twisted or Python Core developer communities are fairly small, so we need to be careful not to burn resources in complicated release procedures. Also, the "batteries included" philosophy has helped both Twisted and Python quite a bit, so we need to explore separating releaseable chunks and still having a large, integrated release which makes it easy to assume that lots of functionality will be available if Twisted is installed without mixing and matching a bunch of little pieces.



3. Network Hostility Management
   
   How hard is it to build a system which would send arbitrary files from any network-connected computer to any other on the internet? How much help do you need from servers on the "real" internet? Most importantly, to what extent can you hide all the nasty details from the user? I would like to outline and discuss a file-transfer tool which can defeat as many kinds of firewalls as reasonably possible without being a security hole itself that firewall admins will attempt to close off.
   



4. Quotient Infrastructure
   
   A discussion of the "big picture" when it comes to Atop, Nevow, and Quotient's app-server-like components, for those of you who have attended both DP's and my presentations. Discussion (and hopefully delegation) of separating application and infrastructure.
   



5. Component Model Experimentation
   
   We're still tweaking the semantics of Twisted's component model, but obviously this has the potential to break a good deal of client code if we release changes. How can we map the core set of semantics that most people currently care about onto a potentially changing back-end?



6. Twisted Imagination
   
   Either this is your life's true purpose or you just don't care. I would like to talk about maybe, you know, writing a working game this decade.

I can think of a few more ideas, but this is probably enough for at least two conferences. Thoughts?

I've been quiet because I'm digging in and trying to get ready for our inital launch / beta at Divmod soon. I'm really excited to have the project get "out there".

, upon seeing the schedule for the Discovery and Learning channels -

"Why is it always about the forensic evidence and the dead bodies? When are the dinosaurs on!"