I would recommend finding one or two developers (I have two) who are willing and potentially wanting the same arrangement. Location has been a non-issue with clients, as one of them is in Pennsylvania, the other in South Carolina.
When starting / launching big projects, we create a shared Google Doc about who the client is, contact info, where the code is, where the app is hosted, etc. We all have each others' SSH public keys, so they can be proactively added to projects, servers, etc. with little effort. This is great for making it easy for them to help with emergencies when on vacation as well. Clients eventually ask the question, so I'm now just very up-front about it that there will be 3 people on the project -- sometimes they want NDAs signed by all of us, but usually signing an NDA as JK Tech is sufficient. I've had it only one time where the client declined continuity on a dev project because they didn't want these other guys to see their code, so it was completely the client's decision. When we did will/trust stuff for the family recently, I went as far as writing my 1Password master password down and storing it in a safe deposit box (free at Chase with biz accounts), among other credentials that don't change often. These guys know of its existence and know to ask my family for it if needed. Totally morbid, but not unreasonable. We're doing a lot more than just development -- hosting private clusters and such, so we can't (and wouldn't want to) rely on clients paying for all recurring services elsewhere. +1 on Rob's comment on the selling point of Rails. If a client asks, this it's totally a valid argument that anyone familiar with the framework could come along and pick it up within a few days/weeks. While I agree with Matt that companies can deal with the fact that people come and go, I try to do my best to ensure continuity because helping these companies transition smoothly gives me peace of mind knowing that no one is going to go after my family for financial recourse. I would also just hate for my wife to have to deal with tying up loose ends simply because I was unprepared. James On Thu, Dec 13, 2012 at 11:39 AM, Matt Aimonetti <[email protected]>wrote: > Contractors disappear everyday (taking a full time job, moving on to > becoming musicians in South America or just stoppin working for you). It's > the same thing with employees, they leave, get fired, get pregnant etc... > If your client really wants continuity he/she should go for a big > consulting company signing a big fat check, get a SLA and 5 lawyers talking > about all the details of what would happen if... > > The reality is that on your own, you can't really promise continuity and > while you might find smart ways to work around it (ask your friends to > promise they will help, document your code, write tests, use GitHub etc...) > you just can't be sure it will work. It's the same problem with HD > redundancy, you can't do raid5 on one disk ;) > > The only way I know how to somewhat limit the risks is to follow the unix > mentality and keep things small, simple and replaceable. > If we are talking about any type of complex app, I would disagree that > Rails is a good example, anyone who tried to upgrade a Rails 1 or 2 to > Rails 3 knows it can be a mess. Currently trying to swap a mobile > notification system from a legacy app, I'm pulling my hair hoping I'm not > breaking anything. > Metaprogramming makes things really complicated and clever code is found > everywhere. As a matter of fact Java frameworks are probably easier to take > over even if the code will hurt your eyes :p > That said you can write Rails code that is encapsulated, easy to trace > (well defined entry points) and has a limited amount of dependencies. > > So at the end of the day, I agree with Marvin. Depending on the client, > the project and the vision, you have to make compromises, but these > compromises aren't free and clients/bosses should be made aware of that. > > - Matt > > > On Thu, Dec 13, 2012 at 2:17 PM, Scott Olmsted <[email protected]> wrote: > >> andle the "what if I were hit by a bus" problem by making sure that my >> client owns his domain, pays for the host and other services directly, has >> all passwords needed, has access to the code, and in general has everything >> he needs to hand the project to someone else (this also makes it real easy >> to fire clients if necessary). I have taken over projects where not a >> single one of those conditions applied, everything being owned and handled >> solely by the prior developer. Prying some of those away from an absent >> developer was not easy in some cases, it would have been impossible if he >> had been > > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
