
When to Rewrite from Scratch – Autopsy of Failed Software - perseus323
http://codeahoy.com/2016/04/21/when-to-rewrite-from-scratch-autopsy-of-a-failed-software/
======
fallous
Unfortunately this is a lesson that often has to be learned the hard way when
you have a lead or team that lacks experience/wisdom. If you can survive that
educational expense, you end up much better for it but it's painful
nonetheless.

Aesthetics are never a legitimate reason to replace a functioning system with
something else. I do not care how it offends the eye, the mind, the ear, or
any other sensation you have... if it does not have a fundamental functional
problem your best option is to maintain or plan an incremental rolling
replacement that is tightly scoped at each step.

For large systems that do present functional problems, identify the egregious
offenders in that system, abstract the entities/behaviors most responsible,
and replace-in-place in a Ship of Theseus fashion. Despite how familiar you
believe you are with a monolithic or complex inter-dependent system, you will
discover how much you don't actually understand about how it works as a whole
if you try and re-implement in its entirety.

~~~
tonyarkles
I perpetually love the references to Ship of Theseus, and find it particularly
applicable to this problem.

You mention fundamental functional problems, and I'd like to add something:
sometimes it's not a functional problem, but a changeability problem. The code
functions fine, but the process of adding a new feature is incredibly painful.

I've done big-bang partial rewrites of systems before, quite successfully, but
I've got a Ship of Theseus rule of my own that I follow: no new features
during the rewrite, and no missing features. The first example that comes to
mind was a rather complicated front-end application that had become a total
spaghetti disaster. It had been written using Backbone, and from my research
it fit the Angular model of things quite well.

I took a pound of coffee with me out to the cabin for a weekend, and rewrote
the whole frontend. Side-by-side. I started with the first screen, and walked
through every code path to populate a queue of screens that were reachable
from there. Implement a screen, capture its outbound links, repeat.

Nothing changed, but everything changed. The stylesheet was gnarly too, but I
left it 100% untouched. That comes later. By keeping the stylesheet intact, I
(somewhat) ensured that the new implementation used identical markup to the
old system. The markup was gnarly too, but keeping it identical helped to
ensure that nothing got missed.

48-72ish hours later, I emerged a bit scraggly and the rest of the team
started going over it. They found 1 or 2 minor things, but within a week or so
we did a full cut-over. The best part? Unlike the article, clients had no
outward indication that anything had changed. There was no outcry, even though
about a quarter of the code in the system had been thrown out.

~~~
enobrev
A full rewrite absolutely should not be taken lightly (if ever). It's very
much a last resort and something that requires deliberation and a clear path
to success. You're spot on with your rules - nothing new; nothing lost.

I had a similar experience, sans the cabin. I was hired onto a startup that
already had a functioning app in the wild. The API was written by one of the
founders, who is not a developer in the professional sense, and holds my
undying respect. As an early-stage startup with lots of ideas, we needed to
move fast, and I wasn't going to be able to do so with the existing code base.

I stocked the fridge, locked myself into my tiny Brooklyn apartment, and got
to work. I started by logging all requests to the API in order to ensure I had
all the necessary endpoints covered. Then I wrote integration tests - acting
as an HTTP client - for the entire API.

About a week or so later, once the rewrite was finished, I added automated
tests that compared the output between the two APIs, and once those matched
perfectly, ran it live beside the original API (sending requests to both) and
compared results from real requests to ensure there were no discrepancies.

Besides a couple very small bugs after the switch, it went very well. The user
base was none-the-wiser, besides the sudden uptick in features after the
rewrite. The startup was relatively successful (acquired), and I still work
with those guys from time to time.

~~~
d33
The thing that struck me is that they decided to rewrite the system without
talking to the customer. I believe that if they kind of __sold __this first,
they might have gone a different path.

------
hinkley
I no longer believe in rewrites.

I used to believe that every company gets one rewrite, but only because I have
seen that most places have the patience and the stamina for a little bit less
than a single rewrite, but I was on the fence about whether they were a good
idea anyway.

Trouble is, I could never put my finger on why, other than that it never
seemed to fix the problem. It was a bit like moving to a new city to start
over and finding out you brought all your problems with you.

In the last couple of years I have begin to figure out what I know in a way I
can articulate. The people who have the skills and discipline to take
advantage of a rewrite _don 't need a rewrite_. It's a short distance from
that skill set to being able to break the problem down and fix it piece by
piece. They just need permission to fix key bits, one bite at a time, and
they've probably already insisted on the space to do it, although they may be
clever enough never to have said it out loud. They just do it.

Then you have the people who don't have the skills and discipline to
continuously improve their code. What the rewrite buys them is a year of
nobody yelling at them about how crappy the code is. They have all the
goodwill and the hopes of the organization riding on their magical rewrite.
They've reset the Animosity Clock and get a do-over. However, as the time
starts to run down, they will make all of the same mistakes because they
couldn't ever decompose big problems in the first place, and they lack the
patience to stick with their course and not chicken out. They go back to
creating messes as they go, if they ever actually stopped to begin with. Some
of them wouldn't recognize the mess until after its done anyway.

In short, people who ask for a rewrite don't deserve a rewrite, and would
squander it if they did. It's a stall tactic and an expensive dream. The ones
who _can_ handle a rewrite already are. They never stopped rewriting.

Now, I've left out all of the problems that can come from the business side,
and in many cases the blame lies squarely with them (and the pattern isn't all
that different). In that case it might take the rewrite for everyone to see
how inflexible, unreasonable and demanding the business side is, and so
Garbage In, Garbage Out rules the day. But the people with the self respect to
not put up with it have moved on, or gotten jaded and bitter in the process.

~~~
jrauser
This comment inspired me to recount a story from my time at Amazon:
[https://storify.com/jrauser/on-the-big-rewrite-and-bezos-
as-...](https://storify.com/jrauser/on-the-big-rewrite-and-bezos-as-a-
technical-leader)

~~~
FmrAMZN_TA
I'm a highly biased former Amazonian.

I was expecting some real wisdom in this story, but I don't think this
qualifies him as a technical leader in any way. I don't even think this needed
the cargo-cult-y "leaving the room and coming back with a paper that changes
everyone's mind." Couldn't he have just asked for a plan? And the ROI? That
seems like management 101.

I have no love for him, but he is a genius. This story doesn't do him any
justice (nor is the paper particularly compelling).

~~~
jrauser
My point was not to qualify Jeff as a technical leader (though he is an
excellent technical leader, IMO). Rather, my goal was to give people a sense
for his leadership style, and what it's like to be in a high level meeting at
Amazon.

I'm sorry you find the Rickover memo uncompelling. Speaking as an experienced
engineer, I happen think it's among the best pieces of engineering writing
ever produced.

------
DonHopkins
"While parts of code were bad, we could have easily fixed them with
refactoring if we had taken time to read and understand the source code that
was written by other people."

This is the thing. Many people just HATE and REFUSE to read other people's
code.

Maybe they just don't teach code reading and reviewing in computer science
classes, but they should.

Printing it out on paper and reading it away from the computer is helpful, but
a lot of people write code for wide screens that doesn't print out well, or
they just don't give a shit and it looks terrible even on the screen. And some
people just don't have the stomach for reading through a huge pile of pages,
or think that's below their station in life.

But reading code is one of the best most essential ways to learn how to
program, how to use libraries, how to write code that fits into existing
practices, how to learn cool tricks and techniques you would have never
thought of on your own, and how to gain perspective on code you wrote
yourself, just as musicians should constantly listen to other people's music
as well as their own.

I just don't feel safe using a library I haven't at least skimmed over to get
an idea of how it's doing what it promises to do.

There are ways to make reading code less painful and time consuming, like
running it under a debugger and reading it while it's running in the context
of a stack and environment, looking at live objects, setting breakpoints and
tracing through the execution.

Code reading and reviewing is so important, and it should be one of the first
ways people learn to program, and something experienced programmers do all the
time.

And of course as the old saying goes, code should be written first and
foremost for other people (preferably psychopaths who have your home address,
photos of your children, and your social security number) to read, and only
incidentally for the computer to execute.

~~~
stevetrewick
> _Maybe they just don 't teach that in computer science classes, but they
> should._

Should they? This seems like a classic conflation of computer science with
programming. Perhaps the reason this important craft skill is not taught in CS
is because it has nothing to do with complexity classes, automata theory, etc.

Programming != CS

~~~
Joeri
It may be the case that programming is applied CS, and that a CS grad might
therefore not actually be a decent programmer. However, employers are
considering a CS degree as proof of competency in programming. So, if CS
classes don't teach programming, then they're failing to provide what the
expectation is that people have of that degree.

~~~
DonHopkins
And they're also failing to educate their CS grads as well as they should. I
think every CS grad should have a firm grasp of programming, and I'd consider
a CS grad who doesn't know how to program to have a gaping hole in their
education.

This notion of considering programming a "craft" that's below you gets at the
attitude problem I think a lot of people (not just pure theoretical computer
science graduate students) have towards reading other people's code.

~~~
stevetrewick
Just to be clear. I don't consider it a craft that's below me, I'm a working
progammer. I don't consider the use of the word craft to be in any way
derogatory either. Quite the opposite. I have a knowledge base from CS and a
knowledge base of craft skills that is derived from the practical professional
application of the former. I consider these to be separate domains. The latter
is not in any way a prerequisite for the former. The obverse may not be true.
YMMV.

~~~
chris_wot
Given that all the things you list that are important parts of a Computer
Science course are tools to create better software, why do you consider the
ability to analyse and understand code as seperate from CompSci?

When you are working out the complexity of a program, you need to be able to
read and understand it. It seems to me that if tiu are taught the fundamentals
of CompSci, reading code and understanding good coding practices naturally are
part of the subject matter you should be taught!

------
rdtsc
Software is re-written most often for political reasons, namely for new
developers to leave a mark, and put a good line in their resume. Everyone
likes to read "designed and implemented" on a resume than "maintained and
fixed annoying bugs here and there". We know what looks better, managers know
who they'd move to the next round, and so on.

The only thing is, if there is no software to be written software developers
will always find a reason to write software. Because they get paid full time,
usually above what other professions get paid, to well, ... write software.

I think other reasons such as "it is slow, outdated, not written in <latest-
language-fad>, bad UI", are often brought up and used as excuses. But
underlying reasons are a lot more personal and subjective.

------
ereyes01
Ill-fated code rewrite crusades often seem to be linked with the Second System
Effect
([https://umich.instructure.com/files/884126/download?download...](https://umich.instructure.com/files/884126/download?download_frd=1)
... page 55).

Excerpt:

 _An architect 's first work is apt to be spare and clean. He knows he doesn't
know what he's doing, so he does it carefully and with great restraint. As he
designs the first work, frill after frill and embellishment after
embellishment occur to him. These get stored away to be used "next time."
Sooner or later the first system is finished, and the architect, with firm
confidence and a demonstrated mastery of that class of systems, is ready to
build a second system. This second is the most dangerous system a man ever
designs. When he does his third and later ones, his prior experiences will
confirm each other as to the general characteristics of such systems, and
their differences will identify those parts of his experience that are
particular and not generalizable._

And from the OP, frill by frill :-)

 _I wanted to try out new, shinny technologies like Apache Cassandra,
Virtualization, Binary Protocols, Service Oriented Architecture, etc._

To OP's credit, he took a step back and learned from his mistakes.

Also related... Second System Effect may not only apply for your second system
ever. It may also bite you designing the second system in a new problem domain
you're unfamiliar with. I can admit I've built a few second systems in my time
;-)

~~~
Terr_
I hope/like-to-think that the second-system that focuses on architectural-
features is better than the second-system that focuses on new user-features.

Stuff like "no global variables" or "actually use database transactions" or
"support UTF-8"...

~~~
kinghajj
"Remember that time zones are a thing and not everyone is in
America/Los_Angeles..."

~~~
kuschku
That’s why I personally love most european companies, as most just assume UTC.

~~~
DonHopkins
The gold standard is software designed to be run near the North and South
Poles, like snowmobile and ICBM navigation systems, which need to be able to
switch between all time zones quickly.

~~~
MichaelGG
Why would an ICBM need to use local timezones at all?

I can't imagine any teams up their using more than one timezone anyways.
Perhaps UTC + their home zone?

~~~
jamie_ca
After a 15-year career programming, I'm pretty sure the only sane way to
handle timestamps is everything UTC server side, and let the UI convert to
localtime on display.

~~~
kuschku
Yup. That’s also my solution. Sadly, we’ve had to deal with doing other things
recently, too, as our software was run on servers with the timezone set to
UTC, but the hardware clock being 3 hours ahead of UTC (this is common
especially on old Windows installs).

The result was that the displayed time on the server was local time, but if we
sent it to the client, we got 3h offset there as well.

------
coldtea
> _The development officially began in Summer of 2012 and we set end of
> January, 2013 as the release date. Because the vision was so grand, we
> needed even more people. I hired consultants and couple of remote developers
> in India._

Well, that's already a warning sign. If you don't have the talent to do the
rewrite, consultants and remote developers in India are only going to make
things worse.

~~~
copperx
Wasn't the rewrite was a technical success despite warning signs?

The customer simply didn't want to adopt the shiny new software.

~~~
perseus323
The rewrite was a technical success. But we missed real business opportunities
and completely underestimated the effort of building a new system while
maintaining the legacy one in parallel. In short, we didn't prioritize and
miscalculated big time :-)

The customer confidence in us had eroded because we weren't responding to
their new feature requests in the legacy system. Plus their management didn't
want to take any risks since the new system offered to new features to them
and only benefited us.

~~~
skj
What about responding to their feature requests... in the new system? !

Then they'd have the motivation to make the switch.

~~~
chris_wot
That's the problem. From my reading of the article, their client was, probably
legitimately, concerned with the risk of a cutover to a new and unproven
system.

To implement a new system the client always needs to do UAT. That's actually a
drain on their resources, and if they have a working system it is far better
to have incremental changes made and a regular set if bug fixes than to launch
a new system, then find a raft of new bugs or unexpected changes that need to
be fixed anyway.

Existing systems allow enterprises to operate effectively. New systems almost
always cause unexpected disruption to a business regardless of efficiencies
gained from the new system. And most IT systems are to support the objectives
if the business, they aren't the actual objective if the business. A software
development company can lose sight of this because it IS the objective of
_their_ business :-)

~~~
perseus323
Good point. The UAT was definitely one of the reasons. It was several Excel
spreadsheets long and scheduling it was a pain :-)

Also, it was a hosted service and client saw no value to them- just the pain.
There was risk of service outage during the upgrade that would have had
resulted in the loss of revenue. Also, the client had to provision extra
resources to run Cassandra/SOA servers. In short, it was a lot of work for
them with no benefit to them.

------
chris_wot
This is one of the reasons I love working on LibreOffice. I think most people
acknowledge that LibreOffice is a pretty decent office suite. But it is just
over 30 years old now and it has acreted massive amounts of legacy code, some
questionable design decisions and in terms of often trying to track it in
version control it can be a nightmare if you go back far enough.

But it would definitely be a mistake to rewrite it from scratch. There are
millions of users who rely on it, and it's a massive code base that runs on
three major operating systems - four if you include Android.

Instead, the LibreOffice developers are slowly working through refactoring the
code base. They are doing this quietly and carefully, bit by bit. Massive
changes are being done in a strategic fashion. Here are some things:

* changed the build system from a custom dmake based system to GNU guild - leading to reduced build times and improving development efficiency

* the excising of custom C++ containers and iterates with ones from the C++ Standard Template Library

* changing UI descriptor files from the proprietary .src/.hrc format to Glade .ui files

* proper reference counting for widgets in the VCL module

* an OpenGL backend in the VCL module

* removal of mountains of unneeded code

* cleanup of comments, in particular a real push to translate the huge number of German comments to English

* use of Coverity's static analysis tool to locate thousands and thousands of potential bugs most of which have been resolved

* a huge amount of unit tests to catch regressions quickly

This has allowed LibreOffice to make massive improvements in just about every
area. It has also allowed new features like tiled rendering - used for Android
and LibreOffice Online, the VCL demo which helps improve VCL performance,
filter improvements which has increased Office compatibility and allowed
importing older formats, a redesign of dialogue boxes, menus and toolbars
which has streamlined the workflow in ways that make sense and are non-
disruptive to existing users, and many more improvements which I probably
don't know about it has slipped my mind.

But my point is - if LibreOffice had decided to do a rewrite it would have
been a failure. It is far better to refactor a code base that is widely used
than to rewrite it, for all the reasons the article says.

------
bernardlunn
True story. Similar start. A couple of enterprise customers, kludgy old code.
Changeability was the problem. Decision made for total rewrite. Budget no
probs, team of 10 allocated. I was the guy who sold the deals. Wanted to
assess if we had a disaster on our hands. Asked CTO to explain how team was
constructed. Here is how the conversation went:

Me: tell me about the team

CTO: well it is actually all being built by two guys.

Me: That's crazy. We have a 10 person team.

CTO: Actually I lied, it is actually all being built by one guy. Before you
get me fired, let me explain. One guy just builds prototypes to keep all those
idiotic requests from management.

Me: I knew the guy. Fastest damn developer on the planet

CTO: we just throw his code away. The other guy who we don't let you meet
actually writes the code that works. You see nothing for weeks, then it
emerges and works beautifully.

Me: what do you do with the other 8 guys?

CTO: give them make work to keep them out of the way.

The system was a market success for a long time.

~~~
nyir
That's fascinating, was everyone involved in on the deal, or how did they
manage to keep that under wraps?

------
hibikir
I rewrote from scratch once, after much deliberation and was successful. In my
case, I had some extremely good reasons:

The original codebase was build using good old waterfall, where neither
programmers nor testers had ever met a user in their life. So all the things
that are good about working software kind of go out the window: There are a
lot of abstractions in the code, but they didn't match the user's mental
model, or helped in any way.

My users didn't like the software at all. It might have me their requirements
in theory, but not in practice.

The team that had built the application was pretty much gone, nobody that had
any responsibility in any design decision was still in the company.

I actually had managed to get access to people that actually used the
software, and people that supported those users, so relying on them, I was
able to get a model of the world far better than the original developers ever
did.

300K lines of Java, written over three years by 10+ developers were rewritten
by a team of two in three months. All the functionality that anyone used was
still there, but actually implemented in ways that made sense for user
workflows.

I'd not have dared a rewrite had the situation been better though: Working
code people want to use trumps everything.

~~~
danieltillett
I have always felt that if you need more than 3 developers and 12 months then
the software is too big and the scope needs to be cut down. Better a small
program that does one thing well than a monolith that does everything badly -
why do we never learn from the UNIX philosophy.

~~~
mafro
I think what you're referring to is what the kids call "microservices".

------
pramalin
Survived a complete rewrite for a client just now.

The previous team blindly relied on a single method from Spring framework's
RestTemplate for every rest service calls with SAP backend.

    
    
        ResponseEntity<T> exchange(String url,
            HttpMethod method,
            HttpEntity<?> requestEntity,
            Class<T> responseType,
            Object... uriVariables)
            throws RestClientException

(ref: [https://docs.spring.io/spring/docs/current/javadoc-
api/org/s...](https://docs.spring.io/spring/docs/current/javadoc-
api/org/springframework/web/client/RestTemplate.html))

This forsed them to create object models structured to match the complicated
and inconsitent request and response JSON strings that SAP used, instead of
creating the objects modeled after the business domains. The result was no
surprise was a disaster and the client wasted five months with them and I had
to redo and complete the project still on time.

I still see many teams make their function signatures in Java so convoluted
like below and don't know what hit them.

    
    
        interface ToDoService {
            ListToDoResponse listToDo(ListToDoRequest request) throws ListToDoException;
            AddToDoResponse addToDo(AddToDoRequest request) throws AddToDoException;
            .. and so on ..
        }

~~~
mikevm
Can you shed some light on how to best solve this problem? I'm pretty much in
the same boat with a restful service I depend on.

------
erikb
That guy really has a done a rewrite and then got it back to the point where
it is used. That is what I felt when reading the article. Many people just
rewrite and then complain that their rewrite never gets used. So they don't
draw the important conclusions and the next time they will try it again. If
you really push yourself, your team and the users to using the rewrite and
getting it back on track with the original solution, then you have to go
through all the disappointments of your rewrite not being better than the
original, the real pains you induce in your users, and solve so many problems
you've never signed up for solving because you didn't know that the old, ugly
solution actually solved these as well.

The pain of reading, understanding and fixing/improving the old, ugly
solftware is never that painful. And the value is much more immediate since
your users already use and know the old software.

------
peterbotond
I have incrementally refactored large codebases by committing to a guide of
which constructs to replace with what, what is the final goal and writing test
cases. Once the guide was seen beneficial by other developers, rather they
were forced to use it, they were surprised how well that worked. All this was
behind the scene from the customer and updates bugfixes were going out. Re-
write may be the answer sometimes, many times, a well thought incremental re-
factoring guide is an easier path.

------
cdevs
I'm facing this at work and wanting to rewrite, updates are to slow when one
small change needs 1000 other changes in spaghetti code in piles of scripts...

Difference is we can roll our users over as they renew and in a year after
release all new customers and old will have the same software.

Only about 2000 users not as big as a scale as the story here.

------
brudgers
Jeff Meyerson's interview with David Heinemeir Hanson [DHH] includes rewriting
software. It discusses the reasons rewrites have a bad reputation and the
difference between rewriting because "it's not my code/language/idiom" and
declaring "technical bankruptcy" as an extension of the technical debt
metaphor.

Agree with DHH or not, he's thought deeply about a lot of software development
tropes.

[http://softwareengineeringdaily.com/2016/01/13/the-
evolution...](http://softwareengineeringdaily.com/2016/01/13/the-evolution-of-
rails-with-david-heinemeier-hansson/)

~~~
dham
I listen to every DHH interview I can but his view on a rewrite is different
than others that do rewrites. There is no "second system" per say in his
world. He leaves the old system up for people that still think it works just
fine. Instead of messing up the old versions with upgrades, they leave them up
and if a customer wants to go to new version that is "rewritten" they can.

------
chrisan
What are everyone's thoughts on rewriting in order to simplify your developer
overhead with the likes of React?

We are a small shop and have a non-game app for html, ios, and android. The
non-public (used by less than 30 people) backend has two management interfaces
in, you might want to sit down for this, Adobe Flex. There are 2 full time
developers (1 backend/flex/html and 1 ios/html) and 1-3 part time
(android/ios) contractors depending on workload/deadlines. Everyone is pretty
siloed with mostly 1 additional cross over app.

I have read articles similar to this as well as worked with some greybeards
that carry this philosophy of staying the course and righting the ship rather
than jumpin. However, this siren's song of React is luring me in with their
philosophy of "learn once, write anywhere"[0]. Instead of siloed developers
we'd simply have developers that would feel comfortable in [management
interface/html/ios/android]

[0]:
[https://facebook.github.io/react/blog/2015/03/26/introducing...](https://facebook.github.io/react/blog/2015/03/26/introducing-
react-native.html)

~~~
douche
Sometimes, you've got to dump the old stuff because it is just too painful to
make changes on. I've rewritten more than a couple of projects that I
inherited from less than competent outsourced contractors... Number one, these
projects mostly didn't work, and had so many bugs that I'm not sure how it was
ever shipped software that somebody paid for. Number two, it was all the worst
kind of WebForms and Visual Basic monstrosity. I'm sure its possible to write
non-terrible code with WebForms that looks good, but I've never seen it, and
it was a matter of a couple weeks to burn it down and build a proper MVC
application instead. My only regret there is that I waited too long to
rewrite, and wasted a few months battling the manure pile of the old version
and trying to improve it incrementally.

------
CraigJPerry
I want to try a re-write project at least once in my career. I've been
thinking about how I might tackle it:

The legacy system components are unlikely to have ideal boundaries (unless
you're insanely lucky) due to organic growth. So step 1, identify key
boundaries and implement them as libraries / micro services / whatever makes
sense.

Step 2, identify the highest value component to refactor - that might not be
the part that makes the system go better for the users, it might be tackling
the bit generating most support noise so you can free up more dev resource.

Begin the refactoring with a release, the new component begins life as a shim
between the component interface and the legacy component, calling out to the
legacy component for all features initially but as functionality is migrated
to the new component it gradually uses the legacy component less and less.

You can always release at any time and you'll have a system using new code
where it's written and falling back to old code where not.

Lather, rinse, repeat.

Key challenges I see during the refactoring are managing state during the
refactoring of complex behaviors of the original component. It may lead to a
private interface which is more granular but only exposed to the new
replacement component.

Interesting stuff for sure.

------
pg_bot
The only cases where I've seen rewrites work are when the software fails to
consistently complete the task it was written to do. A lot of software is
garbage but gets the job done. When you encounter hot spots its best to slowly
refactor until you get the system where it needs to be. Lots of little changes
mitigate risk, and it is easier to track down bugs if you make a mistake.

------
whichdan
Part of me was really hoping that some startup had written an MVP in Scratch
and was seeing how far it could scale.

------
mtrn
I don't believe in rewrites. But I believe in the evolution of the
understanding, what a system is supposed to do and how to do it.

A customer might have a lofty web-scale vision, the first version is built
with all scaling and no maintenance in mind. You are then faced with a
decision: carry along the visionary nightmare and get almost no real work
done, because the system itself is in the way, or rewrite the system with a
fresh, minimal approach, focusing on a valuable target.

The point being: Software requirements evolve and sometimes, writing a first
version of the software is the spec itself. Just as with specs, you can try to
scavenge all good things from the previous version for the next one - and
actually getting better over time, despite being in a rewrite mode.

------
hoodoof
The new Software Development Manager always wants to rewrite the code from
scratch. That's the way it's always been. I like that the guy who wrote this
post had the courage to admit that he was motivated partly by the desire to
play with new tech. reply

------
sferoze
I recently faced the decision whether to rewrite

I took over a rails + angular 1 codebase from another developer who left the
company. I would be working on the project for few months.

I rewrote the entire app with Meteor + React in few weeks. Best decision I
ever made. Even though the app has same features, customers say the app is
faster, has less bugs, and overall feels more solid. Security is also better
because of the pub/sub system. It also gave me a chance to fully understand
the ins and outs of the database and how the app works.

I can also develop features much faster with Meteor + React than with Rails +
Angular 1. So time spend re-writing is saved by enabling faster feature
development.

------
freework
> The development officially began in Summer of 2012 and we set end of
> January, 2013 as the release date.

This is the problem right there. In my experience, successful rewrites only
happen when they get done quickly. If you know exactly what you're re-writing,
you can get it done within a few days. If you have no idea what you're doing
and think it'll take more than a week, it will probably end in failure. The
truth is, I re-write code almost every day in my programming life. I usually
don't realize I'm rewriting something until after the fact.

------
_navaneethan
"Incremental change is always better for testability and validating the
existing features"

\- from _97 things every programmer should know_

------
wink
Interestingly I've hardly seen this 'rewrite' vs 'no rewrite' debate regarding
to microservices, with all the talk about them.

In theory it shouldn't be more work (as they are supposed to be so small) than
some refactoring in your old (big) piece of software, and you can even rewrite
it in a different language.

------
craigvn
I think there are only two reasons to rewrite.

1) When you need to support a different platform, ie we have a Windows Desktop
app and want a Web or Mobile or Mac.

2) When the code base is so bad adding any new features creates many time more
bugs.

------
Ace17
A lack of design skills and code-cleaning skills can mislead you into thinking
"the code needs to be rewritten from scratch".

However, as the new code grows, you're going to need badly these very skills
anyways.

------
jv22222
This is why all developers should build their own framework from scratch in
their spare time... It scratches the itch and helps one appreciate existing
software.

------
tekism
"and changed our protocols to binary, all at the same time. "

What does the author mean by that statement?

