3 ms·

The part I find hard convincing people of is not that this is a good idea but that it is always a good idea and always possible. Everybody thinks it's a good i

by pydry 3y ago

The part I find hard convincing people of is not that this is a good idea but that it is always a good idea and always possible. Everybody thinks it's a good idea. But, their particular problem is a special snowflake that requires a big bang refactor and there's just no way around it.

steveBK123 3y ago
It's funny how many people push for big bang rewrites and how few people have actually seen a successful big bang rewrite. I've been at 5 shops across nearly 20 years. I've been on teams mired in promising to do a big bang rewrite of our own system. I've been on teams that had competitive teams hired to try to replace our system. I've never seen it work, not once. It is a herculean, multi-year, double-your-current-budget effort requiring you to throw most of the functionality of your existing system out the window. It just never works out. The naiveté is incredible. I've seen promised 6 month rewrite projects escalate into 2 year projects, and fail.. leaving the existing system live another 10 years.
- berkes 3y ago
  I've worked on many "Big Bang Releases" and consider all of them a poor choice. Even the single one that was a huge success: in hindsight, I would've rather migrated that through the strangler-vine-pattern¹. Yes, it worked out fine. We even managed to migrate it rather in budget and on time. The release went OK, and we didn't experience crucial data-loss or lost customers. So by all metrics it was a success. And even then: I won't do it like that again. Because part of the success was just random chance: if the dice had fallen just different, it would've been a much worse migration. And I don't like leaving such stuff over to chance. edit: ¹ https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html
- treffer 3y ago
  The thing I am seeing there is rather a dislike of the codebase than a desire to rewrite. My rule of thumb is this: you need to touch a codebase _more_ to throw it away. Tell that to whoever wants to rewrite. You will have to maintain the old application anyway (yes, this is a given, you are not getting an exemption for security holes) and you will have to de-risk the project by providing value (== release early, release often, continuously switch parts over - which requires work on the legacy side, too). If someone wants to do a big bang rewrite then you need to fight for the importance to touch the "legacy" codebase. That is the actual reason why people are so religious about their rewrite. Other than that: same thing, ~20 years and nothing good comes out of big bang rewrites and releases.
  - steveBK123 3y ago
    That's what one should do, but I generally see the incentives setup all wrong. The most common scenario is that the fresh young smart ** hoodwinks the boss into giving them 1-2 years and 2 subordinates to help them do the rewrite in isolation. They come off all support rotas and have no responsibility for BAU operation of the old codebase. The old codebase is left with usually a same or larger team maintaining and still adding new features. The other way I've seen this done is that senior management really wants the rewrite, shops around for a candidate internal or internal who promises to do it.. and then basically same setup as above. Setting up an explicit "good" and "bad" team creates awful vibes, the "good" team never delivers and starts exiting as accountability starts to creep in. Meanwhile the "bad" team hemorrhages staff continuously from the burn out of maintaining the old thing with less people while also being told your job has an expiration date.

by pydry 3y ago

steveBK123 3y ago

It's funny how many people push for big bang rewrites and how few people have actually seen a successful big bang rewrite. I've been at 5 shops across nearly 20 years. I've been on teams mired in promising to do a big bang rewrite of our own system. I've been on teams that had competitive teams hired to try to replace our system. I've never seen it work, not once. It is a herculean, multi-year, double-your-current-budget effort requiring you to throw most of the functionality of your existing system out the window. It just never works out. The naiveté is incredible. I've seen promised 6 month rewrite projects escalate into 2 year projects, and fail.. leaving the existing system live another 10 years.

berkes 3y ago
I've worked on many "Big Bang Releases" and consider all of them a poor choice. Even the single one that was a huge success: in hindsight, I would've rather migrated that through the strangler-vine-pattern¹. Yes, it worked out fine. We even managed to migrate it rather in budget and on time. The release went OK, and we didn't experience crucial data-loss or lost customers. So by all metrics it was a success. And even then: I won't do it like that again. Because part of the success was just random chance: if the dice had fallen just different, it would've been a much worse migration. And I don't like leaving such stuff over to chance. edit: ¹ https://martinfowler.com/bliki/StranglerFigApplication.html https://martinfowler.com/bliki/StranglerFigApplication.html
treffer 3y ago
The thing I am seeing there is rather a dislike of the codebase than a desire to rewrite. My rule of thumb is this: you need to touch a codebase _more_ to throw it away. Tell that to whoever wants to rewrite. You will have to maintain the old application anyway (yes, this is a given, you are not getting an exemption for security holes) and you will have to de-risk the project by providing value (== release early, release often, continuously switch parts over - which requires work on the legacy side, too). If someone wants to do a big bang rewrite then you need to fight for the importance to touch the "legacy" codebase. That is the actual reason why people are so religious about their rewrite. Other than that: same thing, ~20 years and nothing good comes out of big bang rewrites and releases.
- steveBK123 3y ago
  That's what one should do, but I generally see the incentives setup all wrong. The most common scenario is that the fresh young smart ** hoodwinks the boss into giving them 1-2 years and 2 subordinates to help them do the rewrite in isolation. They come off all support rotas and have no responsibility for BAU operation of the old codebase. The old codebase is left with usually a same or larger team maintaining and still adding new features. The other way I've seen this done is that senior management really wants the rewrite, shops around for a candidate internal or internal who promises to do it.. and then basically same setup as above. Setting up an explicit "good" and "bad" team creates awful vibes, the "good" team never delivers and starts exiting as accountability starts to creep in. Meanwhile the "bad" team hemorrhages staff continuously from the burn out of maintaining the old thing with less people while also being told your job has an expiration date.