
Why do we fall into the rewrite trap? - iamjfu
https://www.justindfuller.com/2020/01/why-do-we-fall-into-the-rewrite-trap/
======
jasode
A reminder that Joel Spolky's essay being cited is about people rewriting
_ugly_ code that already works.

That nuance is important because successful companies do invest in rewrites
when there's an _architecture_ change because it's the cleanest most
economical way to do it. My previous comment of Microsoft examples:
[https://news.ycombinator.com/item?id=19245653](https://news.ycombinator.com/item?id=19245653)

Another example is Google rewriting their early web crawlers of Python/Java
into C++ to make them more efficiently scalable to thousands of machines. They
also rewrote the frontend web server from C++ to Java.

But some rewrites also failed such as Evernote's rewrite to C#/WPF.

I think for the topic of "rewrites bad/good", it's better to list a bunch of
famous real-world case studies and extract the common criteria that makes
rewrites successful.

~~~
hn_throwaway_99
I think the ironic thing about Spolsky's example is that, in the end, it
worked. It eventually gave birth to Firefox. So I think there are many lessons
to be learned about _how_ to do a rewrite, how to message it, how to do it in
a way that it doesn't stop other forward progress. But if a rewrite fails,
that doesn't necessarily mean that _not_ doing a rewrite would have been any
more successful in the end, and that's the trap I think people fall into.

~~~
goto11
Joels article was written in 2000 and Firefox 1.0 was eventually released in
November 2004. In the meantime they lost almost all their market share. They
eventually won some of it back, but this was probably only because Microsoft
had stopped all development of IE and disbanded the IE team.

Usually you can't count on you competitors stopping all development for half a
decade.

Obviously you _can_ rewrite from scratch and end up with a fine product, since
the original version of the was developed from scratch. The question is if you
can accept losing all customers and wasting years of effort.

~~~
btilly
There is still more to the story though. When Netscape went under and open
sourced their code, they had to rip out all of the proprietary bits. The
result? What they had didn't actually run!

It wasn't a question of rewriting working code. It was a question about
whether the better path forward was to try to fix what they had and didn't
understand, or whether to rewrite into something that they understood.

In other words, Joel set up a straw man argument.

~~~
goto11
They could just rewrite the components which they didn't own, then. They would
have to do that anyway.

I'm not sure what you mean with "didn't understand". It was their own code.
They could just read it.

~~~
btilly
_I 'm not sure what you mean with "didn't understand". It was their own code.
They could just read it._

I meant exactly what I said.

The missing proprietary bits were not their own code. There was nothing to
read and no documentation. They could see the call, and that something
important happened, but what it did and how it should work was guesswork.

Furthermore key people were gone. How the code that they had was supposed to
work is harder to dig out than you might think. Read
[http://pages.cs.wisc.edu/~remzi/Naur.pdf](http://pages.cs.wisc.edu/~remzi/Naur.pdf)
for an explanation of why.

Just to add to the fun, just getting the browser running wasn't enough.
Netscape and IE were incompatible all over the place, on everything from how
styling worked to what order event handlers ran. (In IE, the thing you clicked
on gets the event first. In Netscape, the window did. That's a pretty
fundamental difference!) They needed to not just have a running browser, but
have a browser with enough IE compatibility that it could be usable on
webpages designed for IE. It is easier to design something to be compatible
from scratch than to find out what deep assumptions need to be changed in
existing code to fix incompatibilities.

As fun as it was for Joel to beat up on them for their choice, their choice
was arguably the best way forward given the actual situation.

~~~
jasode
_> The missing proprietary bits were not their own code. There was nothing to
read and no documentation. They could see the call, and that something
important happened, but what it did and how it should work was guesswork._

To your point, the following link is another famous example of smart
programmers not being able to easily understand someone else's source code.
Raymond Chen at Microsoft couldn't easily figure out why Pinball didn't work
in 64bit Windows and gave up:

[https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=58...](https://devblogs.microsoft.com/oldnewthing/20121218-00/?p=5803)

~~~
goto11
I'm sure they could have figured it out if it was important enough. They just
decided it was not worth it and scrapped the product instead.

"we couldn’t afford to spend days studying the code trying..."

So the estimated time to fix the bug was on the scale of days. It would
certainly have taken longer to rewrite the game from scratch if that was the
alternative.

------
austincheney
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.

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's expense and risk, which is perhaps the greatest crime of
Agile.

~~~
BurningFrog
> _I have also noticed that in Agile teams refactoring is generally not
> rewarded and sometimes is even discouraged_

As a long time Agilist, the spread of Fake Agile is a sad thing to see.

Constant refactoring is a _core_ Agile practice!
[https://martinfowler.com/bliki/OpportunisticRefactoring.html](https://martinfowler.com/bliki/OpportunisticRefactoring.html)

~~~
Ididntdothis
I always get nervous when “refactoring” shows up on the backlog and then gets
deprioritized. In my mind it should never show up as a separate task and then
it should never get ignored . It should just be a normal part of the workflow
for professional development that gets done without much fuzz. Most long term
technical debt can be reduced a lot by proactively refactoring small things
that for some reason don’t work well.

When I worked closer to production the people at the workshops also cleaned
and repaired their equipment every evening, crunch time or not. They didn’t
just let their machines die long term because it may buy some time in the
short term to skip maintenance.

~~~
ShamelessC
This has been my experience. Carving out time for refactoring explicitly is
only beneficial when your stakeholders, PM's, etc. understand its importance
completely. Usually, at least one person up the chain says "it's already
working and we have more important things to focus on. Put it on the backlog
indefinitely."

Better to just incorporate refactoring into the estimate for any given coding
task and do it without explicit permission. Unless of course you're in a
culture that is willing to straight up miss a deadline in order to get
refactoring finished.

~~~
Ididntdothis
“Better to just incorporate refactoring into the estimate for any given coding
task and do it without explicit permission.”

It should be as implicit as attending planning meetings. For some reasons PMs
usually have no problem forcing people to sit through meetings but they have a
problem with spending the same amount of time refactoring .

~~~
Archit3ch
Evidently the answer is refactoring _during_ meetings. /s

~~~
ShamelessC
Sarcasm not needed. I've probably done this during a meeting. I definitely
code if it's an all hands on deck meeting that gets hijacked by technical
discussions that aren't relevant to my work.

------
hinkley
One of the oft-unspoken things about refactoring is that it's a way to do a
rewrite without anyone noticing. Essentially it's the Ship of Theseus gambit:
[https://en.wikipedia.org/wiki/Ship_of_Theseus](https://en.wikipedia.org/wiki/Ship_of_Theseus)

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.

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's healthy or not comes down to a lot of
factors, but the odds are in favor of it being unhealthy.

~~~
darau1
I rewrote two applications, once on my own, once with some help from the team.
The first time we switched the backend to a completely new framework (I'm in
the middle of one of those right now...) and the second time we upgraded from
an outdated version of the framework to the latest one in one go (so,
essentially a rewrite from the ground up).

Both times sucked, both times we underestimated the amount of work to be done,
and both times we were much happier with the new product than what we had
before.

~~~
hinkley
If the team refuses to work on the old code, you have to do something. A
rewrite may be the least bad thing you can do in that case, but if you don't
ask how we got here and why we won't end up right back here again...

The Relentless Improvement model that many refactoring advocates espouse is
one (great) answer to that question. But it also means they won't wait for a
rewrite. They'll fix the bullshit they're staring at today, and stare at some
other bullshit tomorrow.

~~~
mntmoss
Lately I've been testing a "third way" of thinking about refactor/rewrite
decisions, which is to first document the existing requirements.

The trick is in making those docs so small and lean that they fit neatly in
comments inlined with key functions, and this I have accomplished by reduction
to a list of "must" and "cannot" (abbreviated to + and -) bullet point items.
It must function like this, it cannot function like that. Some requirements
can be turned into automated tests or static checks, others need an eye to
verify. But the cycle I'm seeing often works out to be: write speculative
requirements, write speculative code, then reverse-engineer true requirements
and maintain code against that.

Doing this creates a base quality bar that the code has to hit in both the
rewrite and refactor cases. The trap that rewrites tend to fall into is that
the requirements are lost during the rewrite, so the new code becomes just as
speculative as the original greenfield code. If you have the requirements as
your reference, on the other hand, the area of bad code you can write is
limited to the boundaries of those requirements and any missing requirements.
This makes new code much less of a gamble.

~~~
hinkley
That's a very good point.

It's so hard to get people to write good requirements that we often overlook
(or rather, won't look at it) as a solution.

Rewrites are easier with good requirements. They're a constant stream of bad
surprises without them.

It's possible, while refactoring, to begin to collect those requirements, in
the tests if nowhere else. But it's not a given.

------
scarface74
_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._

And then he makes the same mistake that his entire article is based on. He
_needed_ 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.

~~~
radicalbyte
It depends, I've some some beasts built in ASP.Net Webforms. Worse than
anything you'd see in PHP from a reliability and extensibility perspective
(although factors better in security - Microsoft pushed their kludgy ORM hard
back then whilst PHP tutorials started with string-based SQL).

If I inherited an ASP.Net Webforms product which was built by amateurs from an
MVP/PoC which would go on to form a very small part of a large product then I
would absolutely re-architecture (and thus rewrite) it.

If it's an existing product the the rewrite cannot be compartmentalized then
there's no way I'd touch the code.

In the scenario of an aging product I think that you're honestly better taking
your best engineers and product people and starting again. At some point when
the new product is mature enough you can look at how to move the last
straggling customers over. I've seen that done successfully by clients and
also by large companies (Microsoft with WebForms > MVC and later .Net
Framework > .Net Core).

~~~
martinald
WebForms is pretty similar to Coldfusion. Which he spent the whole start of
the article saying was fine and got the job done.

There's nothing inherent in .NET that would 'not provide the type of
experience that was best for this environment'. If anything, probably the vast
majority of code that is written for managing 401Ks out there is probably
written in .NET or Java.

------
softwaredoug
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.

“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.

Usually when I see just a technologist push for a “big rewrite” they won’t
succeed without management allies or enablers.

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.

~~~
eej71
I agree. I think the other dynamic that I've observed in these situations is
that the technologists who oppose the big rewrite often sound like a wet
blanket who are just opposed to the excitement. The old curmudgeons are just
raining on the parade of excitement.

For some senior executives who are looking to generate passion and excitement
the desire to endorse and support the big rewrite is just too much to resist.

------
hnick
I saw a link here on HN a short while ago (though I can'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.

[https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-
call...](https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-
legibility/)

It seems to capture the idea of The Grand Rewrite fairly well. From the post:

    
    
      - 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
    

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.

------
xondono
My feeling is that rewrites simply don't scale well.

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's why refactor tends to work better, rewrite with a
scope.

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:

    
    
       delay_ms(5)
    

Would yield a 5 milliseconds delay, as long as you weren't in a variety of
modes, the GPRS connection wasn't hang up, and GPS had a lock. It was painful
to think about it, let alone work with it.

I convinced everyone that a total rewrite was necessary, and then I let
everyone keep working on the _old_ code base while I worked on the new one to
add the basic functionalities. Then we started to move product by product,
adding the "extras" 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 "business" logic has
automated testing now).

To this day I'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.

~~~
commandlinefan
> rewrites simply don't scale well.

I learned early on that rewriting a codebase is a lose-lose proposition: I’ll
never suggest or recommend it again. Not because I don’t think it’s ever a
good idea, but because it can only go wrong. If everything happens perfectly
without a single hiccup or surprise, you’re still right back “where you
started from” from the perspective of management. I worked on a massive
rewrite porting a C++-based codebase to Java. The rewrite was actually
suggested by “the business” because they were having trouble finding C++
developers and they noticed that Java developers were easier to come by. I was
actually hired because I had a strong background in both, so I jumped right
tin. I was too young and too naive to realize how backstabbing, conniving, and
treacherous business people can be: I actually ended up being blamed for every
surprise that came up during the rewrite process.

------
magicalhippo
Another aspect I didn'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's been used for a bit, the requirements change
and the solution might end up being a poor fit.

Very often in my experience this is because the client doesn'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'ing a solution that doesn't exactly
match the ideal work flow.

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.

Then, when the inevitable changes come, we're in a much better position to
determine the true requirements if we decide to go for a bespoke solution.

This does however require that the code is malleable, so I write with that in
mind.

------
scarface74
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.

If your website was Flash heavy, you had to rewrite it for it to work on
mobile.

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/Newman
integration tests.

After that, we slowly started moving the code from PB to C#.

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/or to get new employees.

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.

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#.

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.

------
gumby
Probably the best section is right here:

> 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.”

~~~
gowld
Combine that with "Red, Green, Refactor" (write failing tests, fix code
refactor) and we have another pair for the list of mutually contradicting
proverbs.

~~~
regularfry
They're different development phases. If you've got a green test suite, you
can just "Refactor, Green, Refactor, Green".

------
mbesto
> _Just like in Joel '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 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.

Even so, there are other, better ways to move toward new technology without
rewriting an entire codebase._

Interesting that the author doesn't provide any real suggestions to this
specific case, only the other examples, which are not similar.

The facts are the following:

1\. The Coldfusion community is dying.

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 "SaaS
Revenue". 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.

These two situations have serious economical ramifications on a company
running CF.

~~~
slowmovintarget
When the answer to "what is your pricing?" is "well... how much can you pay?"
the vendor gets kicked out on their tuchus in our shop.

~~~
gowld
How much do you charge your customers?

~~~
marcosdumay
Well, I work in a government so...

But anyway, the problem of that behavior is not really the pricing, it's all
the rest that comes bundled with that attitude.

------
softwaredoug
Rewrites are a symptom of orgs that focus only on feature velocity, and not
other forms of customer value.

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.

A rewrite for the sake of a rewrite, because X doesn'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.

In short, there shouldn't be a difference between new feature delivery and
refactoring to support some other customer need (like uptime or performance).
It's all work that needs to get put into a backlog, prioritized, and delivered
with clear success outcomes

------
zzzeek
Don't fall into the trap of "never do X" 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're getting into on either side, you'll learn
soon enough, and experiencing both approaches many times over is part of what
being a programmer is about.

~~~
goto11
If you are just developing for your own enjoyment, sure, you can rewrite for
the learning experience or for fun.

~~~
zzzeek
if you are clever enough, you can get your employer to go with either approach
you choose and you can learn while getting paid.

------
caseysoftware
> _If your reason for rewriting the code is that you don 't understand it, you
> should not rewrite it._

This is a fundamental thing that most people miss.

If you don't understand the code/system/structure/process/law, you can't
possibly rewrite it in a way that is a) effective and b) addresses the use
cases it was designed to address.

If you try to rewrite something you don't understand, everything after that
decision is re-discovering the same old pains, lessons, and practices that the
first person discovered.

------
carl_sandland
This notion of code being "done" is the root problem. This idea that you write
something and ship it and that'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's understanding, of the architecture : it
will and must change.

Viewed through that lens you can see;

* estimation is hard, as you are never _really_ done.

* software has a very high maintenance cost, plan for it.

* architecture and design are important, longer term : spending more money on things with longer value life just makes sense.

* Interfaces are important and allow for rewrites on a smaller scale.

* you will always be releasing: focus on CI and devops to take the grind out of that.

Rewriting is a form of refactoring I guess: It'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.

Yeah and oh man I hate the "this code sucks" culture :(

------
rb808
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.

~~~
pjmlp
Those are the same companies that 5 years down the line discover why all big
corporations bet on .NET and Java when performance matters.

~~~
code_sloth
"Nobody ever got fired for buying IBM", or so the industry said for decades.

But IBM wasn't (always) the best, they were just safe bets. Until the world
started changing and they weren't.

.Net and Java have always been good enough. Even today they're good enough for
many, many problems.

I probably would not reach for .Net and Java if performance literally
mattered.

~~~
marcosdumay
> I probably would not reach for .Net and Java if performance literally
> mattered.

There are many tiers for performance mattering. It is quite possible, and
common, for Python to be too slow while .Net is fast enough.

------
GrumpyNl
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.

~~~
Ididntdothis
A lot of rewrites end up trading one set of problems with similarly sized set
of different problems.

But to be honest the rewrite was probably a positive for the devs. They have
more cool stuff on their resume and will do better in the market. That’s one
of the big problems with finding jobs. If you do what’s good for the company
you may quickly end up with an outdated resume and be marked as dinosaur who
hasn’t been keeping up. Even your own company will hire new people for new
sexy projects instead of the people who did what was good for business.

------
notacoward
10% necessary to fix the code itself

20% necessary to get into a better ecosystem (especially for hiring)

30% NIH

40% know it's bad but padding review/resume

------
mark-r
> _If your reason for rewriting the code is that you don 't understand it, you
> should not rewrite it._

Which is just another example of Chesterton's Fence:
[https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...](https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence)

I once lived through a complete application rewrite. The rewrite was necessary
to add a new feature that didn'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.

~~~
mpweiher
And again: _it depends_. I was involved in at least one rewrite where large
sections of the original code were incomprehensible, and rewriting the whole
thing from scratch proved a massive success.

------
pron
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't actually rewrite so much; in fact, they probably do it less than
they should. Yes, there is a "contempt culture" but it almost always comes
from the losing side. E.g. Go is not very popular outside the US, but it's
_hugely_ popular in America; how popular is it in the US for _active_
development? 33x _less_ than Java [1]. That's still very respectable, but
let's not get carried away. Moreover, HN and Reddit are not only terrible at
describing the current state of the industry, they're also terrible at
predicting trends. While a few of the ideas/language/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've failed.

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're supposed to. This means that by their nature they focus on things
people _don 't_ actually do. For another, these forums can, at best, represent
the content that'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 _aren 't_ usually done, and overrepresent smaller problems
and practices that come from inexperience. That makes them fun to read, but
readers shouldn't forget that the genre they're reading is more that of
GQ/Vogue than, say, the New York Times.

[1]: [https://www.hiringlab.org/2019/11/19/todays-top-tech-
skills/](https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/)

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

------
0xff00ffee
This came up a few weeks ago regarding crypto.

There's a distinct difference between rewriting code WITH a regression suite,
and rewriting code WITHOUT a regression suite.

The difference is enormous.

I come from a hardware background where the # of employees looks like this:

lead architects = N employees microarchitects = 10 * N employees circuit
designers = 10 * 10 * N employees validation = 10 * 10 * 10 * N employees

It is rough, but true: 10 lead architects can equal 10's of thousands of
validation engineers

There'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.

The answer to the question, "Should we rewrite?" is always "maybe", 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.

It is not an easy decision for established software. Or rather, it shouldn't
be! :)

------
snarf21
I agree. Mostly you need refactoring to account for the changes in
requirements over time. We don't spend enough time focusing on encapsulation
and modularization.

People want to rewrite because it is green field and they can do it how they
want. As you said, this doesn't really add value to the company.

------
ablekh
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.S. By "rewrite the product" I meant rewriting only the backend.

------
luord
Depending on the size of the refactor, the lines between it and "rewrite"
start to blur, so I'm just going to consider what I'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.

Really, it's pretty much a rewrite of the database handling code but hey, that
won't impact how the data is sent through the endpoints so the interface
didn't change. Refactor!

------
resu_nimda
What if the rewrite was intended to be competing product rather than a
replacement for the existing one?

So many rewrites die as they attempts to reach parity and acceptance from
users of the legacy version.

When a startup comes along and "disrupts" 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.

So, why not just do that whole process in-house?

------
baud147258
The company where I'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 &
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.

Well we'll see in a few years how it ends.

------
WrtCdEvrydy
> Coldfusion (you've probably never heard of it),

I still use it.

------
jldugger
> One of my favorite reads is Joel Spolsky'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.

I'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's downfall was their own fault?

------
bob1029
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.

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).

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't worried about your extremely
pedantic code policies (of which we have many).

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'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.

I would also say that just because you decide to do the rewrite doesn't mean
you have to throw away the old code and any support for it. The most
successful rewrites I'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/B comparison capabilities throughout the
migration phase.

------
growlist
Sometimes there'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'm open to offers!

------
pjmlp
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 / analysis report.

Rewriting stuff is cool when one isn't paying the work hours expended in them.

~~~
thrownaway954
it's called investing in your product. if a rewrite will cost x amount in
dollars and man hours upfront, BUT will save much more over the lifetime of
the product in support and pain for both you and your customer, then it is
ALWAYS worth it.

~~~
pjmlp
If that is proven for the use case in question, by all means.

If not, then there are better places where to spend money.

------
m4r35n357
Because we did it wrong the first time.

~~~
apcherry
but it'll be so much better the second time!!
[https://news.ycombinator.com/item?id=22104506](https://news.ycombinator.com/item?id=22104506)

------
crimsonalucard
I feel if you need to rewrite something you're already in the trap. Rewriting
is climbing out, not rewriting is digging deeper.

The problem with rewriting though is sometimes it's another trap, but anytime
you feel the need to rewrite... you are already in a trap.

------
mr_nobody
The only times I had to rewrite the software was the time when initial
documentation, didn't match what was actually delivered/expected from the
client. Sometimes it's very hard to plan architecture when the whole concept
change.

------
mpweiher
While you should be careful about rewrites, Joel is not correct that a rewrite
is always a bad idea. I've been (reluctantly!) involved in a bunch of rewrites
in my career and they were invariably highly successful.

So, as always:

1\. it depends, and

2\. please use your best judgement.

------
hasbroslasher
Parable: Company wants to move "into the cloud" and adopts AWS managed
services or Kubernetes to recreate and re-platform existing and functional,
though sketchy, on-prem services. "Agile coaches" and "Solution Architects"
advise rewriting the old code because of its fundamental alien-ness in a
cloud-only environment. So it's a rewrite. But of course, the re-write doesn't
work, primarily because of fundamental misunderstandings about what properties
allow software to scale across many machines, in many time zones, running
processes 1000'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't just iterate on the original sketchy code in the first place.

There are times when rewriting does make sense - rare though they may be. I'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 "completely reimagine what software could be doing for your
business". I've helped to rewrite subscription-management systems that ended
up noticeably reducing churn and cutting out spurious chargebacks from
customers who couldn't navigate our bug-prone subscription service wasteland.
But some refactors are so labor intensive that they amount to re-writes, even
if you'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't need to exist.

But, again, if the reason for a refactor or rewrite is summed up as "we're
bored and want to play with these new shinies" 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 "so
much better than what we do now", then it should work so well with what we do
now so well that it doesn'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'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.

------
cratermoon
Does anyone know the error handling pattern the author mentions?

------
aidenn0
Something I'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.

I think the truth is that it's actually a different skill, and one that's much
harder to pickup because when you write code, there's a very quick feedback
loop telling you that you're wrong, but you can read code, think it does
something different than it does and never ever learn you were wrong.

~~~
Ididntdothis
I think reading code is very good for one’s character. It teaches compassion
and openness to other people’s ideas. Pretty much like listening without
prejudice. I am very guilty of not being interested in what other people did
so now I am making a point to really trying to understand code before
criticizing. It’s so much easier to throw a fit and think everybody else is
stupid.

------
luxuryballs
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?

------
Sophistifunk
People not wanting to write Cold Fusion isn't "contempt culture", it's an
objectively terrible platform.

------
krn
But isn't Firefox Quantum a result of a successful rewrite of Firefox Gecko?

~~~
cwzwarich
Firefox Quantum isn't a rewrite of Gecko. At one point, Servo was going to be
a rewrite of Gecko, but that petered out. They pivoted to a strategy where
some parts of Servo would be integrated into Gecko, and other components of
Gecko would be rewritten in Rust. The most significant of these was Stylo,
Servo's CSS style (but not rendering) subsystem. However, despite the
rebranding, the core of the engine and the overall architecture is still
Gecko.

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

------
cottonseed
Obligatory comment I have to repost every time rewrites come up:
[https://news.ycombinator.com/item?id=11554288](https://news.ycombinator.com/item?id=11554288)

