Raising the Bus Number
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.)