Sunday
Feb152009
Raising the Bus Number
Sunday, February 15, 2009 at 3:57AM
One of the concerns that customers sometimes have when hiring a small Rails shop - that is, one with a single active Rails developer - is with the low "bus number" for their projects. The bus number, if you haven't heard the term before, is the number of developers who have to be hit by a bus to put a project in serious trouble. If you're a lone-wolf consultant, then the bus number for projects you undertake is usually 1: if you get run down, the client has no idea what to do next.
Recently I've been experimenting with arrangements to help out small shops with this issue. I've become convinced that one way to handle this is to put into place a formal backup developer arrangement, where work can, in case of emergency, fall back to another developer - without the client incurring charges for this backup service if it's never used.
The basic idea is simple: make sure that there's a developer waiting in the wings to take over in case of emergency, and make sure that the client knows how to get hold of the backup developer. There are a few things to think about if you want to set up this sort of arrangement:
Does this make a one-man shop the full equivalent of a giant Rails consultancy with twenty developers? No, of course not. But it does give those of us who offer our clients small-scale, cost-effective, reliable development one more way to assure them that we have their needs in mind.
(If you're a small shop interested in setting up this sort of arrangement, feel free to drop me a line.)
Recently I've been experimenting with arrangements to help out small shops with this issue. I've become convinced that one way to handle this is to put into place a formal backup developer arrangement, where work can, in case of emergency, fall back to another developer - without the client incurring charges for this backup service if it's never used.
The basic idea is simple: make sure that there's a developer waiting in the wings to take over in case of emergency, and make sure that the client knows how to get hold of the backup developer. There are a few things to think about if you want to set up this sort of arrangement:
- Make sure the client has full contact information for the backup developer, including email and phone.
- The backup developer should sign a separate NDA with the client.
- Ideally the backup developer should have a billing rate not wildly different from the lead developer.
- The backup developer needs to have access to all applicable passwords and logins for things like deployment and staging servers.
- The lead developer needs to be conscientious about putting everything into source code control and making backups.
- The lead developer should use web-available source code management and issue-tracking systems, and the backup developer should have logins on these systems.
- The arrangements should be reviewed on a regular basis.
Does this make a one-man shop the full equivalent of a giant Rails consultancy with twenty developers? No, of course not. But it does give those of us who offer our clients small-scale, cost-effective, reliable development one more way to assure them that we have their needs in mind.
(If you're a small shop interested in setting up this sort of arrangement, feel free to drop me a line.)
Reader Comments (2)
Very interesting read and a good term for it ... I am certainly going to be using that term with clients :-)
Trying reduce the risks for clients is always a good thing, even if you're not a budding startup... sadly though, most of the time you only see budding startups care this much for their clients.
At my little shop we give clients full (read-only) access to the SVN repository for their projects, when they sign the contracts.
I'd be interested in this and my customers might be also. I give my customers their own git repository (on their server or GitHub) so they have the code to their project. I just don't think they have access to developers to replace me if I'm "hit by a bus"