For the past five years or so I’ve been working for a very small web development company, as part of the dev team. This team consists of just three people (four if you count the sysadmin, who has done some development work from time to time), one of whom only works part-time.
During this period, the working practices of the team have been very informal, and have developed organically (or haphazardly, depending on your point of view). We do have source control, even if we only use it in a very shallow way. But there is no formal documentation process; no unit testing; no routine code or security reviews; no documented coding or commenting standard.
And until recently, we didn’t even have a formal means to report bugs — it was done (sometimes) by email but more often by someone shouting across the office in the hope that the relevant developer would hear (over the music coming from their headphones), take notice (rather than just ignore it and hope the person would go away) and do something about it (instead of saying “ok, I’ll look into it” and then instantly forgetting all about it).
Reading back over that lot, it sounds like the intro to the sort of horror story that’s regularly featured on Worse Than Failure. In truth, it has worked surprisingly well and there really haven’t been any significant disasters to speak of. Yes, broken code has on occasion made it to the production server but it has never caused irrevocable damage. Bugs have got lost, but only ever minor ones because the big ones are usually fixed immediately.
I am aware of how lame the above paragraph sounds.
For some time I’ve been arguing to improve our working practices. The main motivation being simply that we’re looking to take on new staff in the near future, and I believe that a larger team simply won’t function effectively (at all) with such a laissez-faire approach.
The first step on this course was the introduction of Trac, and it’s been something of a revelation. We have auditioned issue-tracking software before, but nothing ever quite stuck (notably Request Tracker which was far too scary and complicated). But the simplicity of Trac is just right for us: someone creates a ticket, assigns it to the relevant person, it goes into a list. The relevant person can add notes, reassign it, change its priority and so forth. It does the job.
The real clincher with Trac, though, is its integration with our source control software of choice, Subversion. Using some basic markup when committing, it’s simple to associate a particular changeset with a given ticket (or tickets), giving a quick way to update the ticket’s progress and record its relationship to the code.
Interestingly, the simple fact of having a list of things to do has increased developer productivity: the sense of achievement in being able to close a ticket shouldn’t be underestimated. For the first time in a while it really feels like the software is advancing.
An added bonus is that it gives non-developers — especially management — an appreciation of just how much is getting done. It’s not always easy for non-technical people to understand the nature of our job, but just being able to see a list of all the tasks that have been completed, or at least identified and catalogued, is a useful insight for them.
On top of that, the simple wiki functionality has given a new impetus to documentation efforts. Now, rather than face (and then run away from) the monumental task of writing documentation for the codebase, it’s a simple matter to note things down as you go along, building the information up progressively.
There’ll be people out there for whom none of the above is a revelation. What has surprised me has been the degree to which such a small alteration to our working practices has changed and improved the productivity of the team. Yes, I wish I’d pushed harder, sooner, and had this in place years ago.
Next on the list is to improve our use of source control; set up a staging server; and introduce at least some unit testing. Pop back in five years or so and see how I got on…