3 ms·

What I always love about “the rewrite” is the sheer optimism of the people involved - “we’ll be done in six months, and the new system will be a thing if wonder

What I always love about “the rewrite” is the sheer optimism of the people involved - “we’ll be done in six months, and the new system will be a thing if wonder”. Fast forward to several years later. The original proponents will have moved on leaving behind the accumulated bodges and shortcuts from the increasingly desperate efforts to try and get something live… and then the cycle repeats. There are ways to do this properly, but no one wants to put the effort into understanding the existing code base and the reason for why it is the shape it is. Everyone is happy with the “who wrote this crap - we can’t work on it” line.

bakuninsbart 3y ago
I've only witnessed one full rewrite in my (admittedly short) career so far, and it went shockingly well. The goal was to rewrite a C++ application from the 90s in Java, since the company had largely moved to the web and C++ devs were getting close to retirement. The C++ application was also written in the underfunded startup phase, and then over decades new features had been "tagged on", so the architecture wasn't that robust. The team tasked with the rewrite set a goal to finish in a year, the first 4-6 months were entirely spent on planning. After that, features were implemented in a modular and iterative approach. I think overall it took a bit longer than a year to be feature complete, but by the end of the year they had a working platform with all the core features implemented. I think the key here really was very good planning, and the pitfalls you describe can be at least partially ascribed to agile development not being the right tool if you have a very clear and large set of requirements.
- SenHeng 3y ago
  Would you mind elaborating on the kind of planning that went on? I’ve been involved in instances of planning that meant writing out pseudo code in the whiteboard for the entire software, including errors and exceptions and the final task was ‘just write the code!’. It started off well when coding the big picture modules but as we started getting into the details, bugs, unexpected race conditions and more started coming up.
  - bakuninsbart 3y ago
    I wasn't involved myself, just talked over lunch to some of the guys on the team. The customers for the software are other businesses, each with a pretty large contract volumne and direct negotiations, which meant there was already a lot of documentation on the actual requirements of the customers. From that a ranking of core requirements was compiled, a ranking of requirements that would need to be fulfilled due to current contracts, as well as a ranking of requirements that would probably be required in the future. I think that was most of the first two months. In addition they probably scouted out options for tech stacks. With that in hand, the rest of the time was basically spent with UML and Figma. So very large iterative class diagrams and User Journeys -> UI/UX. I think by far the largest advantage they had is that the project manager and several devs had been with company and the product since the 90s, so there was a lot of institutional knowledge on the product and customers. However, after writing the post above I asked the lead how things are going, and they actually still aren't feature complete (3 years on). So while it has fully replaced the old product and 90%+ works, extending to some of the features is still very hard.
- bazoom42 3y ago
  > the first 4-6 months were entirely spent on planning This is the most surprising part of the story. I have never seen this kind of “big design up front” actually work. Can you elsborate on how you made this work?
TheAceOfHearts 3y ago
I think a rewrite is fine as long as it's incremental and well-integrated each step along the way, rather than starting off from scratch. Unfortunately this seems like the sort of lesson each engineer needs to learn through experience rather than hearing someone tell you about it. Live and learn I guess. :)
loveparade 3y ago
I see this story here all the time, but I have never seen it play out in the real world. Most rewrites I've seen have been hugely successful. This sounds more like a sticky narrative that everyone keeps repeating to tell a nice story, get attention, and make them look experienced. In reality, no experienced engineer is so naive as to think that the new system will be a perfect thing of wonder or not look at the tradeoffs made in the old codebase. Reality is more nuanced than these simplistic fictional narratives.
- lazyasciiart 3y ago
  I wish that were true. I’ve seen ridiculous catastrophic failure twice. I still don’t know if they actually believed their own bullshit, or just wanted to do the rewrite and lied to make it happen.

bakuninsbart 3y ago

I've only witnessed one full rewrite in my (admittedly short) career so far, and it went shockingly well. The goal was to rewrite a C++ application from the 90s in Java, since the company had largely moved to the web and C++ devs were getting close to retirement. The C++ application was also written in the underfunded startup phase, and then over decades new features had been "tagged on", so the architecture wasn't that robust. The team tasked with the rewrite set a goal to finish in a year, the first 4-6 months were entirely spent on planning. After that, features were implemented in a modular and iterative approach. I think overall it took a bit longer than a year to be feature complete, but by the end of the year they had a working platform with all the core features implemented. I think the key here really was very good planning, and the pitfalls you describe can be at least partially ascribed to agile development not being the right tool if you have a very clear and large set of requirements.

SenHeng 3y ago
Would you mind elaborating on the kind of planning that went on? I’ve been involved in instances of planning that meant writing out pseudo code in the whiteboard for the entire software, including errors and exceptions and the final task was ‘just write the code!’. It started off well when coding the big picture modules but as we started getting into the details, bugs, unexpected race conditions and more started coming up.
- bakuninsbart 3y ago
  I wasn't involved myself, just talked over lunch to some of the guys on the team. The customers for the software are other businesses, each with a pretty large contract volumne and direct negotiations, which meant there was already a lot of documentation on the actual requirements of the customers. From that a ranking of core requirements was compiled, a ranking of requirements that would need to be fulfilled due to current contracts, as well as a ranking of requirements that would probably be required in the future. I think that was most of the first two months. In addition they probably scouted out options for tech stacks. With that in hand, the rest of the time was basically spent with UML and Figma. So very large iterative class diagrams and User Journeys -> UI/UX. I think by far the largest advantage they had is that the project manager and several devs had been with company and the product since the 90s, so there was a lot of institutional knowledge on the product and customers. However, after writing the post above I asked the lead how things are going, and they actually still aren't feature complete (3 years on). So while it has fully replaced the old product and 90%+ works, extending to some of the features is still very hard.
bazoom42 3y ago
> the first 4-6 months were entirely spent on planning This is the most surprising part of the story. I have never seen this kind of “big design up front” actually work. Can you elsborate on how you made this work?

TheAceOfHearts 3y ago

I think a rewrite is fine as long as it's incremental and well-integrated each step along the way, rather than starting off from scratch. Unfortunately this seems like the sort of lesson each engineer needs to learn through experience rather than hearing someone tell you about it. Live and learn I guess. :)

loveparade 3y ago

I see this story here all the time, but I have never seen it play out in the real world. Most rewrites I've seen have been hugely successful. This sounds more like a sticky narrative that everyone keeps repeating to tell a nice story, get attention, and make them look experienced. In reality, no experienced engineer is so naive as to think that the new system will be a perfect thing of wonder or not look at the tradeoffs made in the old codebase. Reality is more nuanced than these simplistic fictional narratives.

lazyasciiart 3y ago
I wish that were true. I’ve seen ridiculous catastrophic failure twice. I still don’t know if they actually believed their own bullshit, or just wanted to do the rewrite and lied to make it happen.