

Replacing code once it hits big? - tempsevr

flexterra wrote
"Use whatever you know best. This decisions tend not to be so important. If your app becomes real big you will end up replacing most of your code anyway. The most important thing is to build and launch as fast as possible."<p>I'm not a web developer but learning to be one. I hired a few programmers from India to prototype a v1 of a web app. If it ever becomes big, is it really possible to rewrite the codebase? Cause Isn't rewriting a site from scratch considered bad?
======
arkitaip
Complete rewrites are considered bad because over time code accumulates
implementations of below-surface knowledge that often gets overlooked and can
take a lot of time to re-discover. Edge cases, debugging voodoo, pony requests
- there are lots of reasons why this happens. Pseudocode example: if users
A,C,P try to submit report x on dates y1...y3 make sure to remind them of
policy change z. Because this type of code often is very chaotically codified
in the physical world - your German intern, who documented his code in English
and German and passed away last summer in a freak glockenspiel accident, rest
his soul, received a bunch of bug reports through email, the old bugtracker
and fax from your European customers - it may be very easy to miss during the
requirements gathering phase of your rewrite.

On the other hand, if you're about to become as big as Twitter and Facebook
wrt managing users, data, latency and traffic, you'll have to do all kinds of
performance optimizations throughout your entire tech stack. This _might_
involve rewriting your code because your code is based on fundamentally flawed
design decisions (hey, non-concurrent code seem like an fine idea when you
started out with your batch processing but pretty soon you'll need to time
travel if those nightly cronjobs are to be finished in time) or too
cthulhulian to mantain anymore. But then again, 99.99999% of all sites simply
don't consistently experience performance issues on the same level as Twitter
or Facebook, so that's another reason why you should focus on agility and
delivering value instead of performance (unless, of course, performance truly
_is_ a key feature) initially in a software project.

~~~
jdelsman
I think developers should be conscious of the underlying performance
issues/workarounds of their platforms and technologies and implement those
early. There is nothing worse than wasting capital early just because you have
to throw servers at something once you hit exponential growth.

------
scottyallen
Yes, rewriting from scratch is considered bad. However, rewriting from scratch
isn't the only way to improve a codebase. It's also possible to refactor it
gradually, making a series of smaller changes rather than on big change. This
has a bunch of benefits:

\- It preserves all the built up knowledge encoded in your codebase, as you're
never throwing away everything and starting over.

\- It makes it possible to continue feature development during the refactor.
Often with big ground up rewrites, it's necessary to declare a feature freeze,
often for months at a time. Otherwise, the team that's doing the rewrite is
constantly trying to play catch up to the newly developed features.

\- It can be done gradually over time, which decreases the investment
necessary to start seeing some gains.

Many people shy away from incremental refactoring when it comes to making
large scale changes to a code base. They seem messy, expensive, and time
consuming. And guess what? They are. But a ground up rewrite will generally be
even messier, more expensive, and in the long run, more time consuming.

------
AppSec
I have to actually disagree that complete re-writes are bad. Like anything
else, there are very valid reasons for it.

There are several reasons to do a re-write: 1) The technology stack has
changed and implemented new features which will make future maintenance easier
(or has found issues with underlying implementations in older versions).

2) Business process/site design issues have come out for which patching code
will cause undo stress to the code structure.

3) Those edge cases discussed that have been added are causing severe
performance issues because the customer/end user is using the system
differently than expected.

4) Underlying security vulnerabilities.

Now, re-writing/re-factoring for the sake of doing it is probably a waste.

------
petervandijck
Complete rewrites are considered bad, yes.

However, IF the codebase is really, really bad, or your requirements have
changed a LOT, and there is little learning embedded in your code, complete
rewrites may be necessary/useful.

