
Why your programmers fantasize about a big rewrite - NicoJuicy
https://hackernoon.com/why-your-programmers-fantasize-about-a-big-rewrite-256f2604f4f2?source
======
enb
I believe the appeal to be (though fallacious) that with a ground up rewrite
you already have an entire functional specification of the system you need to
build. No need for annoying customer engagements, requirements analysis, spec-
ing, scoping, etc.

With these rewrites do you just abandon maintaining the legacy system and
focus on the new one?

I find it immensely more satisfying to "rewrite" a system using the Ship of
Theseus approach (aka Strangler Pattern). If there are no tests, the first
(and exciting) challenge is to put some behavioral tests in place in an
attempt to protect it from the changes you are about to make.

------
CM30
At the most basic level though, I suspect it merely comes down to:

Building something new is fun, trying to debug, build on or debug something
that already exists is a lot less so.

Well that and the point in the article about how their ideas would be
respected. The guy who builds a whole new system gets a lot more respect from
the management team than the person who keeps it going or fixes bugs.

~~~
jsgo
I inherited a non-OOP C# web application where instead of using Master pages,
they leveraged iframes for achieving similar (with a lot of trade offs). It is
a nightmare, needs to be rewritten but no time available to do it. So in order
to fix something, takes forever. In order to add something new, takes forever.

I couldn't care less about respect considering I'm the only developer on it
and I feel my manager and I have a good, respectful relationship as is. I just
hate having to do fubar math to quote how long it will take to add/update
something and having to put out a number I'd be embarrassed to quote on any
other project.

------
joeblow9999
the vast majority of rewrite movements I've observed or been part of are
clearly, unambiguously due to the fact that:

\- the legacy system is a spaghetti code nightmare \- with arcane and manual
deployment process \- years of band-aid hacks layered over every component \-
inseparable two-way dependencies across all bounded contexts \- inscrutable
data structures \- nearly impossible to debug \- utterly fragile and mostly
undocumented \- riddled with dead code and unused components that merely
confuse the poor soul tasked with debugging \- often so intertwined with
dependent systems that there's a dev "environment" shared across programmers
because no one can develop on their machine.

THIS is why your programmers fantasize about a big rewrite. Every time.

~~~
devmunchies
Boils down to not keeping entropy in check until it’s unweildy.

Maintainence is as important as new feature development.

~~~
itomato
Scholars should begin emphasizing the need to refactor a number of times
during the lifecycle of the software project.

We're not punching decks or estimating effort in terms of KLOCs, but MIS
students still learn a linear model.

------
karmakaze
I have at some time or other agreed with pretty much every view here, ranging
from:

    
    
      - full rewrite replacement
      - piecemeal separation of a function (e.g. search)
      - in-place migration to a desired design
      - side-by-side incremental replacement of functionality
    

Each has it's merits, although I tend to believe developers lean toward
remaking everything themselves and thus try to consciously give more
consideration to alternatives. The most interesting is the side-by-side one
where we could run non-mutating requests through one (Ruby) or the other (Go)
for performance measurements, or through both for correctness comparisons
monitoring all metrics during the migration.

------
squarefoot
Rewriting software from scratch can often be the only sane thing to do when it
gets messed up by quick and dirty patches, but doing that using the latest
"thing" is the worst mistake one could make: by doing so one would simply swap
errors due to bad problem analysis and time constraints with others due to bad
knowledge of the new platform, paving the way for the next rewrite from
scratch, naturally by using the then newest "thing". Just don't do that; there
is no framework/library/language in the world, or any other place in the known
Universe, capable of replacing good problem analysis and familiarity with the
10+ years old tools the programmers know best.

