Hacker News Reader

Comment by k__ | Hacker News Reader

They rip out everything that has been proven shitty and replace it with new stuff. But how do they do it?

I have worked in a few companies and such behaviour almost never happened.

The management always wanted to maintain the old stuff and only resorted to a rewrite, when things were really really bad. "We don't have the time/money" was always the reply. But I had the impression, that a rewrite wasn't that expensive, it always went faster than the first version, without many bugs the first version had and a better structure.

View on HN

Been in a few orgs. I now think "no rewrites" is a good policy for all but a few orgs. Few orgs have the (1) business luxury (time and money) or, (2) the caliber of people and, (3) team motivation (few teams people even want to improve things) to pull off rewrites.

The best orgs do a rewrite usually in the face of sea changes to the technology stack (e.g., containers vs. VMs) or business use (number of users is now 10X of original etc). Bringing key infrastructure in-house is also a decent reason, but the benefit of building expertise in an existing ecosystem vs. full rewrite should be carefully weighed.

You probably have read spolsky's article. It's quite dated by now, but it's still more right than wrong. http://www.joelonsoftware.com/articles/fog0000000069.html

This reads like they tried to replicate 100% of the features in a big monolithic application, which is rather time consuming. :\

When I start a rewrite I check which are the essential features and try to iterate my way to 100% (sometimes the 100% aren't even needed) with many small releases, but every executive fears "rewrites" like the devil....

Sadly, this often leads to a 50% rewrite where key features are missing because I he rewrite team ran out of budget or willingness to code the non-fun parts. Which drives users to misery or competitors.

True story.

But I have the feeling, that a prio-list of the needed features is all that is needed.

People say what they need, you implement it, done.

I mean the way other companies steal your customers IS that they implement a better version of stuff you did. So it's either, they do the rewrite (in their case a first write) or you.

It's all about maintenance cost. It's pretty easy to justify rewriting stuff because as we've grown the older code has been added to, wrapped in things, turned into APIs, all sorts of stuff.

Eventually, it's just better to start again.

For example, right now I'm rewriting something that is currently a PHP program that executes a Python program that runs one of three binaries or calls a REST API and posts results back to another API into a single program.

Just makes sense: easier for developers to maintain, better for SRE to manage when deployed.

So you think devs need to get better at convincing the management?

John doesn't have any trouble convincing me. But, generally, CloudFlare is still a place where the engineering team drives most the decisions. That comes with benefits as well as its own challenges.

That's why having a full suite of tests is important so that we can fearlessly refactor, so that we can replace a part whose needs we have outgrown without breaking other parts of the system, allowing a "rewrite" to happen organically.

Far too often, code grows stale because nobody wants to work on it anymore. Every change is stressful because it could break something else, which means more time wading through unfamiliar and unpleasant code. So, the maintenance programmer patches it with silly putty and duct tape as to not bother any other portion of the system.

A few years of this and it becomes brittle.

If we have a decent suite of tests, however, we can have an application that doesn't need to be rewritten because the maintenance programmer can attack a problem with the confidence that they haven't broken anything else, and so can make the right solution rather than the least invasive solution.

Reply on news.ycombinator.com