3 ms·

On this second-systems effect: Okay, what if the initial system has reached a point of being unmaintainable and a new system is needed, and there just is no way

On this second-systems effect: Okay, what if the initial system has reached a point of being unmaintainable and a new system is needed, and there just is no way to get it to where it needs to go incrementally, because the pathways just aren't there; it's a from-scratch do-over. Now what? Abandon hope? I don't get that. I work at an organization where the second-system is being attempted and jealousy, sabotage, resistance to change and more come into play (why do they get to build it? we should build it! let's tell everybody how much it's going to suck because those guys are stupid! etc) but the danged thing is badly needed.

bcrosby95 4y ago
The second system effect is basically death by 1,000 cuts. You avoid it by designing a new system that you need rather than designing a new system you think you might need in the future. It becomes a problem because you think "we're doing this whole new system, lets add two dozen bells and whistles we don't have or need yet, surely it won't affect time to delivery!" Bzzzt, wrong.
bklaasen 4y ago
That's part of the system. Management is failing if it's not acknowledging and tackling this part of the system that's prepared to destroy the whole to preserve itself.
kqr 4y ago
Every time someone has told me that "it sounds nice to do it incrementally but that just won't work for us" it's because either they (a) lack expertise they would need, or (b) haven't really tried for political reasons. Maybe it's actually true in your specific case, and I'm curious what makes your case different, if you're at liberty to share!
- kerblang 4y ago
  Sorry for the extraordinarily late reply, but: I'm only peripherally involved in this application, but I think it's in part because of hideously bad architecture from the ground up. I know it was written in Cold Fusion, for one thing, which has graduated to the ever-popular Tremendously Expensive Licensing Era, and has major performance and database problems. But yes, politically: There is no desire to make it a "migration" type of problem; transitioning users isn't important from the business perspective. That might be hard to believe, but I think the argument is that dragging the old product through its own muck is a lot slower than building a new product that brings in new business. So, who am I to argue with that? Are we saying, no, no, if you have an old product you must migrate even when the business says you don't need to?

bcrosby95 4y ago

The second system effect is basically death by 1,000 cuts. You avoid it by designing a new system that you need rather than designing a new system you think you might need in the future. It becomes a problem because you think "we're doing this whole new system, lets add two dozen bells and whistles we don't have or need yet, surely it won't affect time to delivery!" Bzzzt, wrong.

bklaasen 4y ago

That's part of the system. Management is failing if it's not acknowledging and tackling this part of the system that's prepared to destroy the whole to preserve itself.

kqr 4y ago

Every time someone has told me that "it sounds nice to do it incrementally but that just won't work for us" it's because either they (a) lack expertise they would need, or (b) haven't really tried for political reasons. Maybe it's actually true in your specific case, and I'm curious what makes your case different, if you're at liberty to share!

kerblang 4y ago
Sorry for the extraordinarily late reply, but: I'm only peripherally involved in this application, but I think it's in part because of hideously bad architecture from the ground up. I know it was written in Cold Fusion, for one thing, which has graduated to the ever-popular Tremendously Expensive Licensing Era, and has major performance and database problems. But yes, politically: There is no desire to make it a "migration" type of problem; transitioning users isn't important from the business perspective. That might be hard to believe, but I think the argument is that dragging the old product through its own muck is a lot slower than building a new product that brings in new business. So, who am I to argue with that? Are we saying, no, no, if you have an old product you must migrate even when the business says you don't need to?