15 ms·

Let's Rewrite Everything

49 points by benn_88 5y ago

phendrenad2 5y ago
Here's the only way you should ever rewrite something: 1) Document exactly what the existing thing does. 2) Write high-level tests for this functionality. 3) Make sure there are no features that will need to be added to it. Make sure everyone is onboard with not adding new features to it. Make sure people understand that adding features to an in-progress rewrite jeopardizes the entire thing. 4) Rewrite it in the original language, reusing those high-level tests you wrote in step 2. 5) Let people know that they can add features again.
lawrencegripper 5y ago
Really enjoy this take on rewrites: > Someone is likely to point out all the problems your rewrite will bring. You’ll find it much easier to convince people if you’ve already throught these through, and you bring them to the conversation yourself. I wish more people did this!
- waynesonfire 5y ago
  > I wish more people did this! What? Think critically? Me too.
theonething 5y ago
> Good luck with your rewrite! I’m sure it’ll be everything you hope it’ll be. It’ll probably be finished way quicker than you expect, and life will be perfect afterwards. The author seems to be generally pro rewrite in his article so I can't tell if this is sarcasm here.
- martinpeck 5y ago
  100% sarcasm
QuadrupleA 5y ago
A classic Joel Spolsky post along these lines: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- vkou 5y ago
  A classic Joel Spolsky post that completely failed to take into account the fact that Netscape rewrote itself into Mozilla, which then went on to eat IE5's lunch.
  - bazoom42 5y ago
    They only ate IE’s lunch because Microsoft stopped development on IE for the better part of a decade. They literally dismantled the IE team. Usually you cannot count on competitors to stop all developmet for half a decade while you rewrite.
  - aliswe 5y ago
    didn't the rewrite take 8 whopping years? if that is true id argue no one's lunch got eaten.
  - ZeroGravitas 5y ago
    I'm a big fan (and user) of Mozilla but this take seems wrong to my memory. Checking Wikipedia, the IE5 timeframe was them reaching their peak before stalling on the infamous IE6, and Firefox (sort of a rewrite of the rewrite) starting to make some small headway as they let IE stagnate. https://upload.wikimedia.org/wikipedia/commons/thumb/2/24/Browser_Wars_%28en%29.svg/600px-Browser_Wars_%28en%29.svg.png https://upload.wikimedia.org/wikipedia/commons/thumb/2/24/Br...
- a-dub 5y ago
  i think spolsky is a bit too dogmatic about this. gentle reminder: they wrote a transpiler for a subset of vbscript so they could port their bugtracker to linux. look up "wasabi"
tinco 5y ago
This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides". I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite an entire project at once. Pick off smaller features first, get a feel for what your new approach will be like before you commit to the big stuff. This will often mean you have to migrate from a monolithic architecture to a services architecture first. This means your project will grow in complexity first. If you're confused about why a project first grows in complexity before shrinking, watch "All the little things" by Sandi Metz, it's the greatest programming talk ever recorded. If your rewrite gets stuck after adding all of that complexity, then you've played yourself. Worst thing that can happen is you rewrite your entire project, some users or customers start using the new project, but you've failed to rewrite everything and some chunk of your users are still using the old codebase. Now you've got twice as much code to maintain. Before you start a rewrite, consider refactoring and rearchitecting the old codebase, there might be a gem in there that just needs some love and attention. That said there definitely are famous successful rewrites, and I think web application backends are especially suitable for rewrites. Most famous are Twitter and LinkedIn, Twitter going from a relational database backend to a more appropriate fan out message queue based backend allowing them to scale beyond imagination. LinkedIn going from a big rails monolith to super fast node.js microservices reducing their hardware costs a hundred fold if stories are to be believed.
- yaohackernews 5y ago
  I just checked out "All the little things" from Sandi Metz. It's incredible! I need to get back here to say thank you for this information!
  - tinco 5y ago
    No problem! I try to spread the word whenever I can.
- eternityforest 5y ago
hw 5y ago
Had met my share of engineers who wanted to rewrite everything from scratch into microservices and the reason they gave was ‘well microservices scales and monoliths dont’ - without taking into account the maturity of the existing application, the scale it already operates at and the scale we expect to operate at, the team resources and skills to required to support the rewrite, and the business requirements and goals.
- otabdeveloper4 5y ago
  > programmers want to program and get paid more The shocker. (That said, yes, motivating developers is a thorny problem.)
  - eternityforest 5y ago
    I wonder if any companies purposely avoid hiring any dedicated professional developers, and have everything done by other professionals who happen to know some code, and how it works. Developers always come with their own perverse incentive. They like the new, the clever, the smart, and the simple, and rarely appreciate the battle tested and extensible.
    - hn_acc_2 5y ago
      Having seen several projects written by people who "happen to know some code," I can tell you there's a good reason this hasn't caught on. These sort of people can work the very foundations of the company into an ungodly quagmire that would send you screaming back to the fad-chaser dev in a heartbeat. Also despite the meme, most mid-senior devs are actually keen on making their contributions valuable to the business, having gotten over this phase of fascination with new tools
      - eternityforest 5y ago
        Mid senior devs do seem to be pretty good. Entry level devs who think they're senior cause most of the trouble.... I've seen some small projects by non-coders that are better than some real devs, because they can be really aggressive about avoiding original code. It might be hacky... but they find ways to leverage stuff that already exists.
RedShift1 5y ago
I think a lot of rewrites happen because new people come along and they are not interested in reading and learning existing code. They just want to write new code and in their mind "the way I do it is better". A prime example is the Javascript ecosystem with such a high churn rate it caused a new kind of burnout: Javascript fatigue. Programmers seem to forget when you throw away code, you're not just throwing away text, you are throwing away years of accrued knowledge.
throwaway984393 5y ago
I knew about this being a bad idea, and I still fell for it. I bet on a big rewrite to avoid cleaning up technical debt. It did not work out well. I'm currently cleaning up the technical debt.
throwaway13337 5y ago
I'm generally against rewrites as they're often shortcuts for new developers that instantly reject a code base as 'too complicated' without understanding it. However, I have had success in rewriting my own code base a number of times. This is a unique situation of a one-man-band that understands the business case, handles support, and every bit that went into every decision of the code base. With this kind of clarity, when you've spent years with the problem domain, you can uniquely rewrite a project to get at the real business case that, now with years of experience, you see what your customers actually wanted you to solve in the first place, or maybe what they evolved to want in the end. Jim Keller advocates rewrites in a similar way as the only way to progress in chip design. I think we could rewrite very basic things in exciting ways with this sort of attitude. For instance, we know a lot more about what we need in a desktop OS, an email client, a search engine, etc. Basic things that have gotten a lot of cruft over the years as they evolved. Taking a fresh look could be rewarding. I guess one could reframe this as 'first principals thinking" but with the caveat that the problem needs to be truly understood. Here's Jim Keller talking about it: https://www.youtube.com/watch?v=Nb2tebYAaOA&t=1361s https://www.youtube.com/watch?v=Nb2tebYAaOA&t=1361s
namelosw 5y ago
I feel there are certain dynamics to the game. Back in the 90s rewrites are everywhere and they fail a lot because people were doing it so recklessly. Nowadays, people are usually too afraid to even talk about it. As a result, many things that could be straightforwardly solved by rewrites were delayed to the point virtually impossible, causing eternal suffering and valuable features blocked forever.
- a-dub 5y ago
  sometimes repair and retrofit is actually a bigger job than a ground up rebuild. depending on the state of things, this may not be discovered until time and political capital has already been committed to the first approach. i think the key is to avoid dogma and remain agile, not in the buzzword sense, but in the literal sense. be willing and able to scrap approaches and reverse course if things start looking worse than anticipated.
gbrown_ 5y ago
Camille Fournier has some excellent talks on rewrites I'd recommend anyone that came here looking for guidance check out https://www.youtube.com/watch?v=2TbwdxFxOtY https://www.youtube.com/watch?v=2TbwdxFxOtY
bazoom42 5y ago
If the current code is crap there is a reason it ended up like that, and the same forces will be in effect to cause the rewrite to end up in the same state. Perform a root cause analysis for why the current code is in a bad state and why it doesn’t improve over time.
- midrus 5y ago
  In my experience, rewrites are most of the time motivated by switching to the latest hyped stack than anything else. Nobody rewrites anything in the same stack/technology.
jordanbeiber 5y ago
Joel Spolsky from 20 years ago: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Very good post, that holds a lot of experience. Unfortunately these things have to blow up in your own face, often more than once, for a lesson learned. > It’s a bit smarmy of me to criticize them for waiting so long between releases. They didn’t do it on purpose, now, did they? Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.
wokwokwok 5y ago
> “If I replace all of this Python code with Go it’ll be SO much faster!” I write a lot of python, and the irony of this comment is that it’s probably true. Worth the cost and time and effort? /shrug Easier and faster to keep implementing features in? /shrug …but out and out faster to build, deploy and run? Yep, probably. Im my experience python applications are slow it’s usually because your user logic is heavily implemented in python, and despite alllll the hand waving, that is, in general still slow. The package manger is slow and broken. It’s painful to deploy. You can probably solve the problem in other ways, by picking parts to move to another language that provides an easy way to expose python bindings… but you know. Make it faster by rewriting in go will probably work, if you only goal is “runs faster”.
alkonaut 5y ago
Rewrites (and other forms of greenfield development) is an important part of my work environment and compensation. Any equation on rewrite vs. maintain that fails to account for what the company and its employers want to be doing will miss an important factor. The ROI of a rewrite isn’t only in new features or performance or subscribers, but in staff retention and overall happiness.
brian_cunnie 5y ago
A co-worker was adamant we needed to spend six months to re-write the application we were responsible for. As near as I could tell, his reasons were the following: - The application was complicated, - The application was written in Ruby, and he didn't like Ruby. - Golang was way cooler. Fortunately our director pointed out that there was no customer value to a rewrite, so the idea was shelved.
sys_64738 5y ago
Depends on the market for the software. Personal experience of those proposing rewrites usually is tainted with NIH syndrome. Different strokes for different folks but refactoring to modularize for targeted rewriting is more viable. New code means new maintenance headaches and probable maintenance on legacy codease.
PeterWhittaker 5y ago
A few of us inherited two code bases from a previous team, both for what are now products but were essentially prototypes. Every release includes new things and rewritten things. If we add new on old, we grow technical debt; if we rewrite too much, fixes and features are delayed too long. It’s a tough balance. Our code and issues are full of comments re how things should be done, with cross references we added as we figured out what things need to change together. As Joel Spolsky notes in the twice-linked post, reading code is harder than writing. Just today I eliminated hundreds of lines of code after writing maybe two dozen over the last few days. The writing and deletion took no time at all. The reading and forensic mental compilation and execution took days and days. That’s our golden rule: change nothing you do not completely understand - and you only really understand it if you can explain it in plain English to someone who doesn’t know the code. The coolest thing is that as we go along doing cool things becomes easier and doing wicked cool things becomes possible. Just this morning we had to force ourselves to remember that entire blocks of code with poor reporting of errors are as they are because until changes we made elsewhere just weeks ago, there was no point in doing better: the better reports had no place to go. But after a major refactor initiated primarily to make maintenance and addition easier, we can now do things with dramatic - and wholly positive - UI/UX impacts that were simply impossible before. Read read read read digest digest cogitate muse read read correct read confirm, explain, write.
ThinkBeat 5y ago
I think this is how it should be in a more perfect world. and the purest implementation of an iterative development process. The first implementation you write is and will always be a (throw away) prototype. You learn a lot. You understand much more of the spec. Maybe users got a go. Maybe its just internal. Now your write the first version. It is better. You understand even more. Writing a proper prototype first used to be a thing. As we all know once a prototype was getting close to finished the budget changed and bam your prototype is in production. It is not all that practical with huge applications. Perhaps there is a lesson in that.
ZeroGravitas 5y ago
The book Working Effectively with Legacy code has some real advice for when you find yourself in this situation. It's a lot less glamorous than just starting afresh which is where things often go wrong. Here's a recent podcast transcript with the author looking back on the book: https://www.infoq.com/podcasts/working-effectively-legacy-code/ https://www.infoq.com/podcasts/working-effectively-legacy-co...

49 points by benn_88 5y ago

Here's the only way you should ever rewrite something: 1) Document exactly what the existing thing does. 2) Write high-level tests for this functionality. 3) Make sure there are no features that will need to be added to it. Make sure everyone is onboard with not adding new features to it. Make sure people understand that adding features to an in-progress rewrite jeopardizes the entire thing. 4) Rewrite it in the original language, reusing those high-level tests you wrote in step 2. 5) Let people know that they can add features again.

lawrencegripper 5y ago

Really enjoy this take on rewrites: > Someone is likely to point out all the problems your rewrite will bring. You’ll find it much easier to convince people if you’ve already throught these through, and you bring them to the conversation yourself. I wish more people did this!

waynesonfire 5y ago
> I wish more people did this! What? Think critically? Me too.

theonething 5y ago

> Good luck with your rewrite! I’m sure it’ll be everything you hope it’ll be. It’ll probably be finished way quicker than you expect, and life will be perfect afterwards. The author seems to be generally pro rewrite in his article so I can't tell if this is sarcasm here.

martinpeck 5y ago
100% sarcasm

QuadrupleA 5y ago

A classic Joel Spolsky post along these lines: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

vkou 5y ago
A classic Joel Spolsky post that completely failed to take into account the fact that Netscape rewrote itself into Mozilla, which then went on to eat IE5's lunch.
- bazoom42 5y ago
  They only ate IE’s lunch because Microsoft stopped development on IE for the better part of a decade. They literally dismantled the IE team. Usually you cannot count on competitors to stop all developmet for half a decade while you rewrite.
- aliswe 5y ago
  didn't the rewrite take 8 whopping years? if that is true id argue no one's lunch got eaten.
- ZeroGravitas 5y ago
  I'm a big fan (and user) of Mozilla but this take seems wrong to my memory. Checking Wikipedia, the IE5 timeframe was them reaching their peak before stalling on the infamous IE6, and Firefox (sort of a rewrite of the rewrite) starting to make some small headway as they let IE stagnate. https://upload.wikimedia.org/wikipedia/commons/thumb/2/24/Browser_Wars_%28en%29.svg/600px-Browser_Wars_%28en%29.svg.png https://upload.wikimedia.org/wikipedia/commons/thumb/2/24/Br...
a-dub 5y ago
i think spolsky is a bit too dogmatic about this. gentle reminder: they wrote a transpiler for a subset of vbscript so they could port their bugtracker to linux. look up "wasabi"

tinco 5y ago

This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides". I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite an entire project at once. Pick off smaller features first, get a feel for what your new approach will be like before you commit to the big stuff. This will often mean you have to migrate from a monolithic architecture to a services architecture first. This means your project will grow in complexity first. If you're confused about why a project first grows in complexity before shrinking, watch "All the little things" by Sandi Metz, it's the greatest programming talk ever recorded. If your rewrite gets stuck after adding all of that complexity, then you've played yourself. Worst thing that can happen is you rewrite your entire project, some users or customers start using the new project, but you've failed to rewrite everything and some chunk of your users are still using the old codebase. Now you've got twice as much code to maintain. Before you start a rewrite, consider refactoring and rearchitecting the old codebase, there might be a gem in there that just needs some love and attention. That said there definitely are famous successful rewrites, and I think web application backends are especially suitable for rewrites. Most famous are Twitter and LinkedIn, Twitter going from a relational database backend to a more appropriate fan out message queue based backend allowing them to scale beyond imagination. LinkedIn going from a big rails monolith to super fast node.js microservices reducing their hardware costs a hundred fold if stories are to be believed.

yaohackernews 5y ago
I just checked out "All the little things" from Sandi Metz. It's incredible! I need to get back here to say thank you for this information!
- tinco 5y ago
  No problem! I try to spread the word whenever I can.
eternityforest 5y ago

hw 5y ago

Had met my share of engineers who wanted to rewrite everything from scratch into microservices and the reason they gave was ‘well microservices scales and monoliths dont’ - without taking into account the maturity of the existing application, the scale it already operates at and the scale we expect to operate at, the team resources and skills to required to support the rewrite, and the business requirements and goals.

otabdeveloper4 5y ago
> programmers want to program and get paid more The shocker. (That said, yes, motivating developers is a thorny problem.)
- eternityforest 5y ago
  I wonder if any companies purposely avoid hiring any dedicated professional developers, and have everything done by other professionals who happen to know some code, and how it works. Developers always come with their own perverse incentive. They like the new, the clever, the smart, and the simple, and rarely appreciate the battle tested and extensible.
  - hn_acc_2 5y ago
    Having seen several projects written by people who "happen to know some code," I can tell you there's a good reason this hasn't caught on. These sort of people can work the very foundations of the company into an ungodly quagmire that would send you screaming back to the fad-chaser dev in a heartbeat. Also despite the meme, most mid-senior devs are actually keen on making their contributions valuable to the business, having gotten over this phase of fascination with new tools
    - eternityforest 5y ago
      Mid senior devs do seem to be pretty good. Entry level devs who think they're senior cause most of the trouble.... I've seen some small projects by non-coders that are better than some real devs, because they can be really aggressive about avoiding original code. It might be hacky... but they find ways to leverage stuff that already exists.

RedShift1 5y ago

I think a lot of rewrites happen because new people come along and they are not interested in reading and learning existing code. They just want to write new code and in their mind "the way I do it is better". A prime example is the Javascript ecosystem with such a high churn rate it caused a new kind of burnout: Javascript fatigue. Programmers seem to forget when you throw away code, you're not just throwing away text, you are throwing away years of accrued knowledge.

throwaway984393 5y ago

I knew about this being a bad idea, and I still fell for it. I bet on a big rewrite to avoid cleaning up technical debt. It did not work out well. I'm currently cleaning up the technical debt.

throwaway13337 5y ago

I'm generally against rewrites as they're often shortcuts for new developers that instantly reject a code base as 'too complicated' without understanding it. However, I have had success in rewriting my own code base a number of times. This is a unique situation of a one-man-band that understands the business case, handles support, and every bit that went into every decision of the code base. With this kind of clarity, when you've spent years with the problem domain, you can uniquely rewrite a project to get at the real business case that, now with years of experience, you see what your customers actually wanted you to solve in the first place, or maybe what they evolved to want in the end. Jim Keller advocates rewrites in a similar way as the only way to progress in chip design. I think we could rewrite very basic things in exciting ways with this sort of attitude. For instance, we know a lot more about what we need in a desktop OS, an email client, a search engine, etc. Basic things that have gotten a lot of cruft over the years as they evolved. Taking a fresh look could be rewarding. I guess one could reframe this as 'first principals thinking" but with the caveat that the problem needs to be truly understood. Here's Jim Keller talking about it: https://www.youtube.com/watch?v=Nb2tebYAaOA&t=1361s https://www.youtube.com/watch?v=Nb2tebYAaOA&t=1361s

namelosw 5y ago

I feel there are certain dynamics to the game. Back in the 90s rewrites are everywhere and they fail a lot because people were doing it so recklessly. Nowadays, people are usually too afraid to even talk about it. As a result, many things that could be straightforwardly solved by rewrites were delayed to the point virtually impossible, causing eternal suffering and valuable features blocked forever.

a-dub 5y ago
sometimes repair and retrofit is actually a bigger job than a ground up rebuild. depending on the state of things, this may not be discovered until time and political capital has already been committed to the first approach. i think the key is to avoid dogma and remain agile, not in the buzzword sense, but in the literal sense. be willing and able to scrap approaches and reverse course if things start looking worse than anticipated.

gbrown_ 5y ago

Camille Fournier has some excellent talks on rewrites I'd recommend anyone that came here looking for guidance check out https://www.youtube.com/watch?v=2TbwdxFxOtY https://www.youtube.com/watch?v=2TbwdxFxOtY

bazoom42 5y ago

If the current code is crap there is a reason it ended up like that, and the same forces will be in effect to cause the rewrite to end up in the same state. Perform a root cause analysis for why the current code is in a bad state and why it doesn’t improve over time.

midrus 5y ago
In my experience, rewrites are most of the time motivated by switching to the latest hyped stack than anything else. Nobody rewrites anything in the same stack/technology.

jordanbeiber 5y ago

Joel Spolsky from 20 years ago: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... Very good post, that holds a lot of experience. Unfortunately these things have to blow up in your own face, often more than once, for a lesson learned. > It’s a bit smarmy of me to criticize them for waiting so long between releases. They didn’t do it on purpose, now, did they? Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.

wokwokwok 5y ago

> “If I replace all of this Python code with Go it’ll be SO much faster!” I write a lot of python, and the irony of this comment is that it’s probably true. Worth the cost and time and effort? /shrug Easier and faster to keep implementing features in? /shrug …but out and out faster to build, deploy and run? Yep, probably. Im my experience python applications are slow it’s usually because your user logic is heavily implemented in python, and despite alllll the hand waving, that is, in general still slow. The package manger is slow and broken. It’s painful to deploy. You can probably solve the problem in other ways, by picking parts to move to another language that provides an easy way to expose python bindings… but you know. Make it faster by rewriting in go will probably work, if you only goal is “runs faster”.

alkonaut 5y ago

Rewrites (and other forms of greenfield development) is an important part of my work environment and compensation. Any equation on rewrite vs. maintain that fails to account for what the company and its employers want to be doing will miss an important factor. The ROI of a rewrite isn’t only in new features or performance or subscribers, but in staff retention and overall happiness.

brian_cunnie 5y ago

A co-worker was adamant we needed to spend six months to re-write the application we were responsible for. As near as I could tell, his reasons were the following: - The application was complicated, - The application was written in Ruby, and he didn't like Ruby. - Golang was way cooler. Fortunately our director pointed out that there was no customer value to a rewrite, so the idea was shelved.

sys_64738 5y ago

Depends on the market for the software. Personal experience of those proposing rewrites usually is tainted with NIH syndrome. Different strokes for different folks but refactoring to modularize for targeted rewriting is more viable. New code means new maintenance headaches and probable maintenance on legacy codease.

PeterWhittaker 5y ago

A few of us inherited two code bases from a previous team, both for what are now products but were essentially prototypes. Every release includes new things and rewritten things. If we add new on old, we grow technical debt; if we rewrite too much, fixes and features are delayed too long. It’s a tough balance. Our code and issues are full of comments re how things should be done, with cross references we added as we figured out what things need to change together. As Joel Spolsky notes in the twice-linked post, reading code is harder than writing. Just today I eliminated hundreds of lines of code after writing maybe two dozen over the last few days. The writing and deletion took no time at all. The reading and forensic mental compilation and execution took days and days. That’s our golden rule: change nothing you do not completely understand - and you only really understand it if you can explain it in plain English to someone who doesn’t know the code. The coolest thing is that as we go along doing cool things becomes easier and doing wicked cool things becomes possible. Just this morning we had to force ourselves to remember that entire blocks of code with poor reporting of errors are as they are because until changes we made elsewhere just weeks ago, there was no point in doing better: the better reports had no place to go. But after a major refactor initiated primarily to make maintenance and addition easier, we can now do things with dramatic - and wholly positive - UI/UX impacts that were simply impossible before. Read read read read digest digest cogitate muse read read correct read confirm, explain, write.

ThinkBeat 5y ago

I think this is how it should be in a more perfect world. and the purest implementation of an iterative development process. The first implementation you write is and will always be a (throw away) prototype. You learn a lot. You understand much more of the spec. Maybe users got a go. Maybe its just internal. Now your write the first version. It is better. You understand even more. Writing a proper prototype first used to be a thing. As we all know once a prototype was getting close to finished the budget changed and bam your prototype is in production. It is not all that practical with huge applications. Perhaps there is a lesson in that.

ZeroGravitas 5y ago

The book Working Effectively with Legacy code has some real advice for when you find yourself in this situation. It's a lot less glamorous than just starting afresh which is where things often go wrong. Here's a recent podcast transcript with the author looking back on the book: https://www.infoq.com/podcasts/working-effectively-legacy-code/ https://www.infoq.com/podcasts/working-effectively-legacy-co...