Many good comments so far - I also think you should work with him in this situation. I had a similar situation once at a place where I worked, also a not for profit, also a single guy who had built the old system and was the only one who knew all about it (including passwords etc). Alienating him would have been bad, so we (three guys from a the IT department of a different division that got merged) decided to discuss it with him and credited him with the work he had done but discussed what a catastrophe it would be if he were run over by a car tomorrow. We tried to be very honest about it all and tried to get him onboard to update the systems as we went along.
In the end it worked out medium well. He had implemented a database with a very poor design and there was definitely quite a bit of friction when we tried to convince him that normalizing a database is more that just a nice idea:). In the end he left after two years or so later but we could integrate his old systems into the new ones without the fallout of cutting him lose at day one. For the organization it certainly was a very good outcome.
Buy more harddrives. Seriously, just ask yourself how much pain it would be if would loose the data. It's easily worth a couple of hundred dollars/euros.
As for what strategies, incremental vs 1:1 backups etc. I have recently written two blog entries for a filmschool where I regularly teach where they have the same problem - huge amounts of data, little cash, loose organisation. Have a read if you like (the newest blog post covers incremental backups with hardlinks under windows and osx which has some nice properties but is not always the best solution) http://www.danielbachler.de/node/121
A great use case for something like this would be better merge conflict resolution. DVC Systems like git, hg etc work reasonably well for source code for simple changes, but concurrent refactorings in different branches are still a potential headache. If merge algorithms could get easy access to the semantics of the code they try to merge they could be a lot cleverer than just line based diffing. Does anyone know is something like this is already being worked on?
Thank you very much, this was the comment I was waiting for or would have tried to write myself in this discussion.
As a side note, add to the money gained from taxation the money saved from the war on drugs and the immense hit to the income of organized crime, and the economic reasons for legalizing all drugs make a compelling case by themselves.
Let me add that this slashdot discussion has restored some of my faith in humanity. I was getting the impression that this is so far off anybodies radar that no matter how weak the point for prohibition is we are not going to get rid of this nonsense. Maybe, if there will be more slashdotters some day, things will change:)
It's not that black and white. Yes, generally a view should do no processing, but e.g. localization is something that can legitimately be considered a job of the view and is of course something that changes the data (think date formatting etc).
GP got it right, it's a pattern, not a religion. As long as it's well understood by all members of a dev team what they think makes up a pattern and Grey areas like the on I just mentioned are discussed among them, everything is fine.
Slashdot Mirror
Many good comments so far - I also think you should work with him in this situation. I had a similar situation once at a place where I worked, also a not for profit, also a single guy who had built the old system and was the only one who knew all about it (including passwords etc). Alienating him would have been bad, so we (three guys from a the IT department of a different division that got merged) decided to discuss it with him and credited him with the work he had done but discussed what a catastrophe it would be if he were run over by a car tomorrow. We tried to be very honest about it all and tried to get him onboard to update the systems as we went along.
In the end it worked out medium well. He had implemented a database with a very poor design and there was definitely quite a bit of friction when we tried to convince him that normalizing a database is more that just a nice idea :). In the end he left after two years or so later but we could integrate his old systems into the new ones without the fallout of cutting him lose at day one. For the organization it certainly was a very good outcome.
Oh and yes, google docs seems like a bad idea.
Buy more harddrives. Seriously, just ask yourself how much pain it would be if would loose the data. It's easily worth a couple of hundred dollars/euros.
As for what strategies, incremental vs 1:1 backups etc. I have recently written two blog entries for a filmschool where I regularly teach where they have the same problem - huge amounts of data, little cash, loose organisation. Have a read if you like (the newest blog post covers incremental backups with hardlinks under windows and osx which has some nice properties but is not always the best solution) http://www.danielbachler.de/node/121
A great use case for something like this would be better merge conflict resolution. DVC Systems like git, hg etc work reasonably well for source code for simple changes, but concurrent refactorings in different branches are still a potential headache. If merge algorithms could get easy access to the semantics of the code they try to merge they could be a lot cleverer than just line based diffing. Does anyone know is something like this is already being worked on?
Sure, and if they went on a killing spree they would get even more media coverage. The point being?
It certainly doesn't legitimize rioting and looting as a political tool.
Thank you very much, this was the comment I was waiting for or would have tried to write myself in this discussion. As a side note, add to the money gained from taxation the money saved from the war on drugs and the immense hit to the income of organized crime, and the economic reasons for legalizing all drugs make a compelling case by themselves. Let me add that this slashdot discussion has restored some of my faith in humanity. I was getting the impression that this is so far off anybodies radar that no matter how weak the point for prohibition is we are not going to get rid of this nonsense. Maybe, if there will be more slashdotters some day, things will change :)
It's not that black and white. Yes, generally a view should do no processing, but e.g. localization is something that can legitimately be considered a job of the view and is of course something that changes the data (think date formatting etc). GP got it right, it's a pattern, not a religion. As long as it's well understood by all members of a dev team what they think makes up a pattern and Grey areas like the on I just mentioned are discussed among them, everything is fine.