Replacing code once it hits big? | Hacker News Reader

Replacing code once it hits big?

7 pointstempsevr5 comments

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

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?

View on HN

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.

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.

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.

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.

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.

Reply on news.ycombinator.com