Why do we fall into the rewrite trap?

A reminder that Joel Spolky&#x27;s essay being cited is about people rewriting <i>ugly</i> code that already works.<p>That nuance is important because successful companies do invest in rewrites when there&#x27;s an <i>architecture</i> change because it&#x27;s the cleanest most economical way to do it. My previous comment of Microsoft examples: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19245653" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19245653</a><p>Another example is Google rewriting their early web crawlers of Python&#x2F;Java into C++ to make them more efficiently scalable to thousands of machines. They also rewrote the frontend web server from C++ to Java.<p>But some rewrites also failed such as Evernote&#x27;s rewrite to C#&#x2F;WPF.<p>I think for the topic of &quot;rewrites bad&#x2F;good&quot;, it&#x27;s better to list a bunch of famous real-world case studies and extract the common criteria that makes rewrites successful.

Rewriting from scratch is usually, but not universally a bad idea. There are times in your life when you encounter that piece of legacy internal software that is simply garbage. The math is simple if it takes less time to rewrite than to refactor then rewriting is better, but also keep in mind that estimating software efforts is often inaccurate.<p>I have also noticed that in Agile teams refactoring is generally not rewarded and sometimes is even discouraged. Instead it is a voluntary effort taken at the developer&#x27;s expense and risk, which is perhaps the greatest crime of Agile.

One of the oft-unspoken things about refactoring is that it&#x27;s a way to do a rewrite without anyone noticing. Essentially it&#x27;s the Ship of Theseus gambit: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ship_of_Theseus" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Ship_of_Theseus</a><p>Later on I realized a sort of reverse Catch-22 in this: The people who are most capable to do a rewrite are also the least likely to ask for one. They will just do it.<p>An official rewrite often just becomes a pressure release valve. During the early stages nobody can measure how the team is doing, so the team gets a break from scrutiny. Whether that&#x27;s healthy or not comes down to a lot of factors, but the odds are in favor of it being unhealthy.

<i>The company had built heavily around .NET, which, while it has its merits, did not provide the type of experience that was best for this environment.</i><p>And then he makes the same mistake that his entire article is based on. He <i>needed</i> to rewrite the code to use Angular instead of .Net? I’m assuming he meant he needed to use Angular instead of server side rendering. I can’t imagine a scenario where server side rendering wouldn’t have gotten the job done. Especially since he admitted that he didn’t need high UI performance.

In my experience it’s a management problem more than a technologist problem. New engineering manager, wants to leave their stamp, has a grand vision, and is able to get buy in and budget from the higher ups.<p>“Higher ups” in most companies don’t have the tech literacy to question such a move. And there’s a lot of ego going around to say “this time is different” when it’s really not.<p>Usually when I see just a technologist push for a “big rewrite” they won’t succeed without management allies or enablers.<p>One reason this happens is that management and technologists alike have a huge dearth of skills when it comes to dealing with and evolving legacy code. It’s not taught anywhere and has to be learned. It’s this lack of skills that CAUSES a lot of new shiny tech to come out, as it’s more fun to write my own JS framework than try to work with other people to improve theirs.

I saw a link here on HN a short while ago (though I can&#x27;t remember where exactly) to a Ribbon Farm post talking about Legibility, or the idea that people generally like things that can be understood and categorised.<p><a href="https:&#x2F;&#x2F;www.ribbonfarm.com&#x2F;2010&#x2F;07&#x2F;26&#x2F;a-big-little-idea-called-legibility&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.ribbonfarm.com&#x2F;2010&#x2F;07&#x2F;26&#x2F;a-big-little-idea-call...</a><p>It seems to capture the idea of The Grand Rewrite fairly well. From the post:<p><pre><code> - Look at a complex and confusing reality, such as the social dynamics of an old city - Fail to understand all the subtleties of how the complex reality works - Attribute that failure to the irrationality of what you are looking at, rather than your own limitations - Come up with an idealized blank-slate vision of what that reality ought to look like - Argue that the relative simplicity and platonic orderliness of the vision represents rationality - Use authoritarian power to impose that vision, by demolishing the old reality if necessary - Watch your rational Utopia fail horribly </code></pre> There are often good technical reasons for a rewrite or major refactoring, but more than once in my career the urge was definitely based on the fact that if we rewrite it then we will know it inside out and we will only have what we need, nothing more. Full control and understanding.

My feeling is that rewrites simply don&#x27;t scale well.<p>To make them work you need resources, good planning and motivation from everyone involved. As the number of people increase the probability that any of them made a mistake estimating how long it will take or how well their part will run explodes. That&#x27;s why refactor tends to work better, rewrite with a scope.<p>I worked at a company were we build small embedded devices (EM dataloggers). I was supposed to take an existing code base shared by several products and modify it to build a new one. The code was beyond ugly. As an example:<p><pre><code> delay_ms(5) </code></pre> Would yield a 5 milliseconds delay, as long as you weren&#x27;t in a variety of modes, the GPRS connection wasn&#x27;t hang up, and GPS had a lock. It was painful to think about it, let alone work with it.<p>I convinced everyone that a total rewrite was necessary, and then I let everyone keep working on the <i>old</i> code base while I worked on the new one to add the basic functionalities. Then we started to move product by product, adding the &quot;extras&quot; each device required. Now the new products are built with that skeleton, and refactors are way less scary and faster, and can be made across devices easily (one of the improvements is that &quot;business&quot; logic has automated testing now).<p>To this day I&#x27;m convinced that the only reason that could be made is because we started with the new product, and then moved upwards. Trying to build a new ecosystem for all of them would have failed hard.

Another aspect I didn&#x27;t see mentioned was that, at least in my experience, one can put too much effort into solving a problem. Then one ends up with a nice bespoke solution, but once it&#x27;s been used for a bit, the requirements change and the solution might end up being a poor fit.<p>Very often in my experience this is because the client doesn&#x27;t have a perfect handle on what exactly it is they want, which is only natural when venturing into the unknown. So they end up spec&#x27;ing a solution that doesn&#x27;t exactly match the ideal work flow.<p>These days at work, when the client wants some new custom feature, we try to figure out if we can get something good enough by making small adjustments to existing features.<p>Then, when the inevitable changes come, we&#x27;re in a much better position to determine the true requirements if we decide to go for a bespoke solution.<p>This does however require that the code is malleable, so I write with that in mind.

He kind of touched on it, but he really didn’t go into one reason to rewrite code is if it is based on old legacy technology that won’t be supported in the future.<p>If your website was Flash heavy, you had to rewrite it for it to work on mobile.<p>I mentioned another post where I was responsible for rewriting a legacy 20 year old PowerBuilder app that depended on sql server 2003. The first step I took was to upgrade it to a “newer” version of PowerBuilder that supported COM, put a C# REST API on top of it, and then create Postman&#x2F;Newman integration tests.<p>After that, we slowly started moving the code from PB to C#.<p>Honestly though because everyone has their own self interest at heart, sometimes you have to rewrite or transition to newer tech to keep existing employees and&#x2F;or to get new employees.<p>I was at a job where the department grew from 4 to 15 developers in a year. The product was a B2B product where we had 90%+ of the sellers market using a PHP web app with complicated business logic. We didn’t have a product for the buyers market.<p>We were going to put COM on top of the (well written) PHP rules engine and share it with a new product for the buyers written in C#.<p>The buyers product written in C# didn’t find a market, but we were getting interest in expanding the PHP product. Every single developer left within 6 months because no one wanted to spend the next year doing PHP. We all knew that PHP wasn’t marketable at the compensation rates we were looking for. The only reason it took six months for them to leave is because some were waiting for their 3 year vest.

Probably the best section is right here:<p>&gt; However, refactoring can be a better tool before you begin making any changes as a way to make your change easier. As Kent Beck said “Make the change easy (warning: this may be hard), then make the easy change.”

&gt; <i>Just like in Joel&#x27;s post, where Netscape took years to rewrite its already working code, rewriting code because Coldfusion was “dead” or “inferior” would have served little business purpose.</i><p><i>I understand there are plenty of counter-arguments to be made here. First and foremost, it gets harder every day to find a Coldfusion developer. Those who know the platform are most likely looking to give a facelift to their skillset, rather than prolonging the inevitable drying-up of the proverbial job pool. More, it may be harder to implement functionality in Coldfusion, particularly the kind we were dealing with, than, say, in .Net, Ruby on Rails, or even Go.<p>Even so, there are other, better ways to move toward new technology without rewriting an entire codebase.</i><p>Interesting that the author doesn&#x27;t provide any real suggestions to this specific case, only the other examples, which are not similar.<p>The facts are the following:<p>1. The Coldfusion community is dying.<p>2. Adobe is actively making it more difficult to commercially pay for the software. They are now seeking compensation for use of CF as part of &quot;SaaS Revenue&quot;. You have to submit a form that says what your revenues are. I kid you not, thats what the sales people are saying to customers.<p>These two situations have serious economical ramifications on a company running CF.

Rewrites are a symptom of orgs that focus only on feature velocity, and not other forms of customer value.<p>If in addition to getting features done, teams were held more accountable for uptime, performance, and stability, there would be appropriate focus on careful redesign, but only in proportion to some customer end-value after that is delivered.<p>A rewrite for the sake of a rewrite, because X doesn&#x27;t conform to software engineering technobabble is a huge red flag. These things exist to support customer value, and are not ends in-and-of-themselves.<p>In short, there shouldn&#x27;t be a difference between new feature delivery and refactoring to support some other customer need (like uptime or performance). It&#x27;s all work that needs to get put into a backlog, prioritized, and delivered with clear success outcomes

Don&#x27;t fall into the trap of &quot;never do X&quot; prescriptions written in blog posts. Rewriting an application or library from the ground up is often a joyful experience packed with an immense amount of lessons to learn. Similarly, refactoring an existing application and watching it come back to life can also be a joyful experience packed with an immense amount of lessons to learn. Whether or not you know what you&#x27;re getting into on either side, you&#x27;ll learn soon enough, and experiencing both approaches many times over is part of what being a programmer is about.

&gt; <i>If your reason for rewriting the code is that you don&#x27;t understand it, you should not rewrite it.</i><p>This is a fundamental thing that most people miss.<p>If you don&#x27;t understand the code&#x2F;system&#x2F;structure&#x2F;process&#x2F;law, you can&#x27;t possibly rewrite it in a way that is a) effective and b) addresses the use cases it was designed to address.<p>If you try to rewrite something you don&#x27;t understand, everything after that decision is re-discovering the same old pains, lessons, and practices that the first person discovered.

This notion of code being &quot;done&quot; is the root problem. This idea that you write something and ship it and that&#x27;s over is wrong. Code is never done, it is almost biological in its emerging complexities. The current code is the running manifestation of everyone&#x27;s understanding, of the architecture : it will and must change.<p>Viewed through that lens you can see;<p>* estimation is hard, as you are never <i>really</i> done.<p>* software has a very high maintenance cost, plan for it.<p>* architecture and design are important, longer term : spending more money on things with longer value life just makes sense.<p>* Interfaces are important and allow for rewrites on a smaller scale.<p>* you will always be releasing: focus on CI and devops to take the grind out of that.<p>Rewriting is a form of refactoring I guess: It&#x27;s like chopping a leg off or something. One thing I like about microservices (or rather, strict boundaries) is that you can rewrite the worst part but keep the rest going.<p>Yeah and oh man I hate the &quot;this code sucks&quot; culture :(

The most important thing for developers is will they have the skills to get the next job or will they be working on technology that no one wants in a few years time. If FANG companies are hiring people with SPA, JS, Python experience it makes perfect sense to get rid of any technology no matter how well it is working.

The biggest trap is new and shiny. Let me explain, they decided in the company to do a complet rewrite while we only needed a few apis connecting to the existing software. Its a group of 8 people. The current software is written in PhP, jQuery, Mysql and some use of Yii. Blazing fast, customers are happy. New guys come and of course we need a rewrite. Everything has to be microservices. Now they have to work in Kubernets, Docker, React, Node, elastic search, MongoDb. With each of these is nothing wrong, but its a lot of new technology to pickup with 8 people. Now the clients hear when they want a change or modification, no just wait till we have platform 2.0. Long story short, development has gone downhill, customers unhappy and after 6 months they are already 12 months behind schedule. This company will byte the dust within a year.

10% necessary to fix the code itself<p>20% necessary to get into a better ecosystem (especially for hiring)<p>30% NIH<p>40% know it&#x27;s bad but padding review&#x2F;resume

&gt; <i>If your reason for rewriting the code is that you don&#x27;t understand it, you should not rewrite it.</i><p>Which is just another example of Chesterton&#x27;s Fence: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;G._K._Chesterton#Chesterton&#x27;s_fence" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;G._K._Chesterton#Chesterton&#x27;s_...</a><p>I once lived through a complete application rewrite. The rewrite was necessary to add a new feature that didn&#x27;t fit into the existing code organization. We were able to reuse large parts of the old code, but it still took twice as long as estimated. And the result was the most bug-ridden version of the app ever. But ultimately it was successful, and the new feature was much loved.

I would ask a meta-question: why did the author fall into the trap of writing about the rewrite trap? While much of what the article says is true, it talks about a phenomenon that exists mostly in the funhouse mirror of HN and Reddit. People don&#x27;t actually rewrite so much; in fact, they probably do it less than they should. Yes, there is a &quot;contempt culture&quot; but it almost always comes from the losing side. E.g. Go is not very popular outside the US, but it&#x27;s <i>hugely</i> popular in America; how popular is it in the US for <i>active</i> development? 33x <i>less</i> than Java [1]. That&#x27;s still very respectable, but let&#x27;s not get carried away. Moreover, HN and Reddit are not only terrible at describing the current state of the industry, they&#x27;re also terrible at predicting trends. While a few of the ideas&#x2F;language&#x2F;techniques hyped on such forums do end up successful, the vast majority end up failing. Some of them continue to be hyped on those forums even long after they&#x27;ve failed.<p>Why do Reddit and HN paint such a distorted image? I have a couple of guesses. For one, by their very nature, they focus on new and unusual things, which is what they&#x27;re supposed to. This means that by their nature they focus on things people <i>don&#x27;t</i> actually do. For another, these forums can, at best, represent the content that&#x27;s actually produced online, and here there is a big bias towards smaller companies -- perhaps because such content is an efficient form of marketing for them -- as well as towards places and industries where producing blog posts featured on HN is a part of the culture, namely startups and SV companies. Even there we see that an SV company like Google, that employs 2000 times as many employees as a startup, does not produce 2000 times the number of technical blog posts. When the content is so skewed towards small organizations, it gives disproportionate representation to the practices of small companies working on small codebases. When those companies grow, they tend to shift their practices and technologies to more established ones that are not as new and not as unusual, and also produce fewer technical blog posts. Similarly, younger, less experienced developers have more time and incentive to publish posts, and so are overrepresented, but as they mature the often realize, like their predecessors, the mistake of their ways, but also produce less online content. The result is that HN and Reddit mostly talk about things that <i>aren&#x27;t</i> usually done, and overrepresent smaller problems and practices that come from inexperience. That makes them fun to read, but readers shouldn&#x27;t forget that the genre they&#x27;re reading is more that of GQ&#x2F;Vogue than, say, the New York Times.<p>[1]: <a href="https:&#x2F;&#x2F;www.hiringlab.org&#x2F;2019&#x2F;11&#x2F;19&#x2F;todays-top-tech-skills&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.hiringlab.org&#x2F;2019&#x2F;11&#x2F;19&#x2F;todays-top-tech-skills&#x2F;</a>

A programmer never starts from scratch. Every new line of code typed brings with it the legacy of past struggles and new understanding;

I agree. Mostly you need refactoring to account for the changes in requirements over time. We don&#x27;t spend enough time focusing on encapsulation and modularization.<p>People want to rewrite because it is green field and they can do it how they want. As you said, this doesn&#x27;t really add value to the company.

Quick question, since we are on the topic: do you think that it is a feasible (or even the optimal) approach to first develop an MVP, using a very productive, but much less performant, language (Python) and then, upon reaching a product-market fit, if needed [i.e., after trying to remove performance bottlenecks and using a faster compiler, like PyPy], rewrite the product (SaaS platform) in a more performant and otherwise more suitable language (e.g., Julia, C#)?<p>P.S. By &quot;rewrite the product&quot; I meant rewriting only the backend.

Depending on the size of the refactor, the lines between it and &quot;rewrite&quot; start to blur, so I&#x27;m just going to consider what I&#x27;m doing right now at my job a big refactor of how the data is stored and read, even if it involves making some big changes to the database models and how they are interacted with.<p>Really, it&#x27;s pretty much a rewrite of the database handling code but hey, that won&#x27;t impact how the data is sent through the endpoints so the interface didn&#x27;t change. Refactor!

What if the rewrite was intended to be competing product rather than a replacement for the existing one?<p>So many rewrites die as they attempts to reach parity and acceptance from users of the legacy version.<p>When a startup comes along and &quot;disrupts&quot; a product with their fancy new tech, they have basically done a rewrite without caring about the state of the legacy product. And then the incumbent often acquires them for a lot of money.<p>So, why not just do that whole process in-house?

The company where I&#x27;m working is doing a full rewrite of one of its product from a single-tenant, installed on-premise to a multi-tenant solution in the cloud. Except that the previous version is still worked on (new features &amp; fixs), with perhaps less people than a few years ago. And the new version is developed by new teams set up for this project and the targeted market seems a little different.<p>Well we&#x27;ll see in a few years how it ends.

&gt; Coldfusion (you&#x27;ve probably never heard of it),<p>I still use it.

&gt; One of my favorite reads is Joel Spolsky&#x27;s Things You Should Never Do. He wrote this post almost twenty years ago, outlining the downfall of Netscape and others because they spent years rewriting working code.<p>I&#x27;ve read that piece long ago, and over time my cynicism has ripened. Should I be surprised that the opinion of a former Microsoft employee is that Netscape&#x27;s downfall was their own fault?

My policy on rewrites is that you must already fundamentally understand not only the code but also the business that the code covers. If the developer responsible for the rewrite satisfies this constraint, I have a much greater deal of confidence in the success of the effort.<p>Also, any rewrite should be done in contrasting terms of: Value to the end customer VS long-term technical value. Many rewrites remove value from both ends of the scale. Some may improve both. I think as long as you keep this equation balanced you will be ok. Many developers have ulterior motivations which can greatly compromise this equation if not carefully accounted for (e.g. chasing shiny things, resume padding, etc).<p>I would say that in purely technology terms, rewrites are amazing. My approach to writing a new system usually involves writing it 2 times at a minimum. The first pass is the fastest, hacky way I can get to MVP with a major focus on the most difficult technical aspects of the product. This pass is what I put in front of our internal developers to get some input so that I can quickly correct course if needed. During this time, I allow myself to make sloppy mistakes in favor of proving that a certain feature can (theoretically) work. This seems to do wonders for productivity because you are much more likely to experiment and find better paths when you aren&#x27;t worried about your extremely pedantic code policies (of which we have many).<p>The 2nd pass (aka the rewrite) is when I have the first pass project up on the left hand side of my monitor, and a new solution on the right hand side. I use my original implementation as a reference, but now view it through the lens of auditing another developer&#x27;s code for quality and policy. Having already proven that the hard thing can be done, my mind is now free to focus on the correctness and standards applied throughout. This is the code that I would actually put in front of our customers. From this point onward, unless a major shift in framework, architecture or language is decided, all future iterations are done on top of this 2nd pass codebase.<p>I would also say that just because you decide to do the rewrite doesn&#x27;t mean you have to throw away the old code and any support for it. The most successful rewrites I&#x27;ve ever seen occur where the legacy system is ran in parallel with the new system with both being maintained and used in production simultaneously. Obviously this has some overhead, but it also ensures you have a stable fallback option with clear A&#x2F;B comparison capabilities throughout the migration phase.

Usually the way I turn down junior ideas about rewriting the whole deal is making them think about the monetary costs of a rewrite, and to show what is the benefit for the end customer from an cost &#x2F; analysis report.<p>Rewriting stuff is cool when one isn&#x27;t paying the work hours expended in them.

Because we did it wrong the first time.

The only times I had to rewrite the software was the time when initial documentation, didn&#x27;t match what was actually delivered&#x2F;expected from the client. Sometimes it&#x27;s very hard to plan architecture when the whole concept change.

While you should be careful about rewrites, Joel is not correct that a rewrite is always a bad idea. I&#x27;ve been (reluctantly!) involved in a bunch of rewrites in my career and they were invariably highly successful.<p>So, as always:<p>1. it depends, and<p>2. please use your best judgement.

Parable: Company wants to move &quot;into the cloud&quot; and adopts AWS managed services or Kubernetes to recreate and re-platform existing and functional, though sketchy, on-prem services. &quot;Agile coaches&quot; and &quot;Solution Architects&quot; advise rewriting the old code because of its fundamental alien-ness in a cloud-only environment. So it&#x27;s a rewrite. But of course, the re-write doesn&#x27;t work, primarily because of fundamental misunderstandings about what properties allow software to scale across many machines, in many time zones, running processes 1000&#x27;s of times per day. So it becomes necessary to either cut losses and re-write the re-write or decide to start iterating now on the crappy re-write to make it closer in terms of functionality to what already existed in the crappy on-prem systems - which begs the question of why you didn&#x27;t just iterate on the original sketchy code in the first place.<p>There are times when rewriting does make sense - rare though they may be. I&#x27;ve only seen a few, and they always had to do with improving stability and reducing the potential for bugs. None of them required you to use the latest shiny to &quot;completely reimagine what software could be doing for your business&quot;. I&#x27;ve helped to rewrite subscription-management systems that ended up noticeably reducing churn and cutting out spurious chargebacks from customers who couldn&#x27;t navigate our bug-prone subscription service wasteland. But some refactors are so labor intensive that they amount to re-writes, even if you&#x27;re using the same tools and languages. Some code is acutely awful and it needs to die for people to be able to go to sleep at night without having to drink a fifth of whiskey beforehand. Some atrocities don&#x27;t need to exist.<p>But, again, if the reason for a refactor or rewrite is summed up as &quot;we&#x27;re bored and want to play with these new shinies&quot; then you are in for it. If rewriting provides you with some sort of new business capability or fundamentally changes a business process drastically for the better, then go ahead. But in my experience, if a technology or paradigm is fundamentally &quot;so much better than what we do now&quot;, then it should work so well with what we do now so well that it doesn&#x27;t require fundamental rewrites of large software systems. So rewriting things in Python or C++ is great, or using Kubernetes instead of Lambdas or whatever is fine, but it&#x27;s more important that these paradigm shifts can be incremental rather than a complete recreation of what already exists, that the gulf between refactoring and rewriting can be relatively small instead of two completely different processes.

Does anyone know the error handling pattern the author mentions?

Something I&#x27;ve noticed over the years is that the people who say that reading code is harder than writing code are people who have been writing code for a long time and are paid to write code.<p>I think the truth is that it&#x27;s actually a different skill, and one that&#x27;s much harder to pickup because when you write code, there&#x27;s a very quick feedback loop telling you that you&#x27;re wrong, but you can read code, think it does something different than it does and never ever learn you were wrong.

What if it’s written in ASP classic and powered by deprecated SQL procedures that won’t run on anything newer than SQL Server 2005?

People not wanting to write Cold Fusion isn&#x27;t &quot;contempt culture&quot;, it&#x27;s an objectively terrible platform.

But isn&#x27;t Firefox Quantum a result of a successful rewrite of Firefox Gecko?

do we have a model for differential structure migration back to formal specs ?

This came up a few weeks ago regarding crypto.<p>There&#x27;s a distinct difference between rewriting code WITH a regression suite, and rewriting code WITHOUT a regression suite.<p>The difference is enormous.<p>I come from a hardware background where the # of employees looks like this:<p>lead architects = N employees microarchitects = 10 * N employees circuit designers = 10 * 10 * N employees validation = 10 * 10 * 10 * N employees<p>It is rough, but true: 10 lead architects can equal 10&#x27;s of thousands of validation engineers<p>There&#x27;s a reason why it is so upside-down: bugs cost a lot more in the hardware world than in software because they are much harder to fix in the wild.<p>The answer to the question, &quot;Should we rewrite?&quot; is always &quot;maybe&quot;, and then requires risk exposure analysis and a robust mitigation plan. You need regression testing and a bug tracking system from day one, but you also need a rollout plan and a response team.<p>It is not an easy decision for established software. Or rather, it shouldn&#x27;t be! :)

Sometimes there&#x27;s no option, because enterprise policy mandates that you have to port that uncommented, spaghetti code, dependent on archaic Win32 calls, written by amateurs VB6 image processing application to something modern like .NET. BTW if anyone needs that skillset I&#x27;m open to offers!

I feel if you need to rewrite something you&#x27;re already in the trap. Rewriting is climbing out, not rewriting is digging deeper.<p>The problem with rewriting though is sometimes it&#x27;s another trap, but anytime you feel the need to rewrite... you are already in a trap.

Obligatory comment I have to repost every time rewrites come up: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11554288" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=11554288</a>