4 ms·

That's amazing that they purposefully sabotaged it! How did they go about doing so?

jacquesm 11y ago
Well, given that it is much easier to destroy a system than it is to build one in the first place the actual method doesn't really matter much. Take your pick. How would you sabotage a system? In this case they canceled the contracts on a bunch of facilities that were crucial to operating the old system and that would take a very long time to set up again. But the whole idea of a non-revertible change-over without at least a period of having the old system on stand-by just in case all by itself is totally reprehensible, especially since their testing regime was comprised mostly of 'let's go live and see if it works'. Of course they didn't mention that little fact beforehand, only afterwards was it made clear that any attempt to move back to the old setup was going to be fruitless because they'd 'closed the door behind them'. I suspect that they knew full well the new system wouldn't work properly and that if a revert would have been done this would likely trigger some serious backlash so by saddling the client up with the new system and making sure they could not go back they forced them to accept the new situation no matter what. Job security by any means. Only that part ended up not working. I've never seen a clusterfuck like this before and I really hope I won't ever see one again.
- jerf 11y ago
  "How would you sabotage a system?" Just to provide another example, "write a stub prototype of the new system, discover $CRAPPY_ORM in my new hotness language doesn't like a couple of the database constructs, migrate production database to work better with the prototype, new system fails to generate some data the old system needed (history, audit logs, tons of options here)". Back migration now effectively impossible.
  - jacquesm 11y ago
    There is absolutely no reason why you couldn't pair those strategies ;) Especially not if there is financial information involved.
  - woah 11y ago
    Let's imagine that YOU were doing the rewrite, and for all the best reasons. Totally different situation. Would you write your code to continue saving some bizarre unnecessary data in the database, or would you get the job done with a sensible scheme? As for the other comment, were they supposed to continue renting out completely unused facilities in case someone came along who thought the old system was better?
    - jacquesm 11y ago
      There are proper ways of doing this: you run the old system in parallel with the new system and you outfit both systems in such a way that all writes are done on both systems. That way the DBs stay in sync. So you won't have to 'write your code to continue saving some bizarre unnecessary data in the database' and you can have your 'sensible scheme'. It just takes a little bit more care and planning. > As for the other comment, were they supposed to continue renting out completely unused facilities in case someone came along who thought the old system was better? They ended up renting a good part of those facilities anyway, the problem was not the money but the fact that certain comms lines had been torn up. Playing cowboy with critical company data is not a winning strategy.

Well, given that it is much easier to destroy a system than it is to build one in the first place the actual method doesn't really matter much. Take your pick. How would you sabotage a system? In this case they canceled the contracts on a bunch of facilities that were crucial to operating the old system and that would take a very long time to set up again. But the whole idea of a non-revertible change-over without at least a period of having the old system on stand-by just in case all by itself is totally reprehensible, especially since their testing regime was comprised mostly of 'let's go live and see if it works'. Of course they didn't mention that little fact beforehand, only afterwards was it made clear that any attempt to move back to the old setup was going to be fruitless because they'd 'closed the door behind them'. I suspect that they knew full well the new system wouldn't work properly and that if a revert would have been done this would likely trigger some serious backlash so by saddling the client up with the new system and making sure they could not go back they forced them to accept the new situation no matter what. Job security by any means. Only that part ended up not working. I've never seen a clusterfuck like this before and I really hope I won't ever see one again.

jerf 11y ago
"How would you sabotage a system?" Just to provide another example, "write a stub prototype of the new system, discover $CRAPPY_ORM in my new hotness language doesn't like a couple of the database constructs, migrate production database to work better with the prototype, new system fails to generate some data the old system needed (history, audit logs, tons of options here)". Back migration now effectively impossible.
- jacquesm 11y ago
  There is absolutely no reason why you couldn't pair those strategies ;) Especially not if there is financial information involved.
- woah 11y ago
  Let's imagine that YOU were doing the rewrite, and for all the best reasons. Totally different situation. Would you write your code to continue saving some bizarre unnecessary data in the database, or would you get the job done with a sensible scheme? As for the other comment, were they supposed to continue renting out completely unused facilities in case someone came along who thought the old system was better?
  - jacquesm 11y ago
    There are proper ways of doing this: you run the old system in parallel with the new system and you outfit both systems in such a way that all writes are done on both systems. That way the DBs stay in sync. So you won't have to 'write your code to continue saving some bizarre unnecessary data in the database' and you can have your 'sensible scheme'. It just takes a little bit more care and planning. > As for the other comment, were they supposed to continue renting out completely unused facilities in case someone came along who thought the old system was better? They ended up renting a good part of those facilities anyway, the problem was not the money but the fact that certain comms lines had been torn up. Playing cowboy with critical company data is not a winning strategy.