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
