Tips on surviving a rewrite in a mid-large sized company.

1) Get yourself placed on the "Legacy team" that is supposed to "minimally support the application while we transition to the new system".

2) Do whatever the hell you want with the code base (i.e., refactor as much as you want) because nobody cares about the boring legacy system.

3) Respond directly to user/customer needs without having to worry about what upper management wants (because they are distracted by the beautiful green-field rewrite).

4) Retain your job (and probably get a promotion) when they cancel the rewrite.

Alternatively, tips for not surviving a rewrite in a mid-large sized company.

1) Get stuck on the "Legacy team", as expensive contractors are called in to produce the rewritten version from scratch in an unrealistically small fraction of the time the original took.

2) Be told you can only fix bugs (with more layers of short term hacks), not waste time with refactors that have "no business value" for a code base that will be scrapped "soon".

3) Don't add any new features, to prevent the legacy system becoming a perpetually moving target that would delay the beautiful green-field rewrite even longer.

4) Hate your job, and watch your coworkers leave in disgust, further starving the team of resources, until you end up quitting too.

My last two IT jobs ever were both for businesses which cancelled huge rewrites after being sold to another company. Someone up top pitched the businesses as white elephants ripe for massive cost savings half-way during the rewrite.

The programmers with the political skills to get put in the "Rewrite team" will have had their jobs in the "Legacy team" protected in case of project cancellation. Or they will knife you in the back to get their old jobs back -- they will know about the cancellation and have plenty of time to maneuver before you know what's going on.

There is another path to survival:

1) Get on the new team

2) Ensure to get into the more interesting tech modules

3) Improve your CV

4) Use your soft skills to mingle with everyone and be aware of where the wind blows

5) In case of iceberg ahead, jump ship to a better job taking advantage of the new skills

There is yet another path to survival:

1) Do a startup

Or, simpler

1) Quit job 2) move to the woods 3) shun all electrical devices 4) mediate until you become one with the universe

On the other hand, Firefox today is much better than Netscape ever was. And with the never re-write philosophy we wouldn’t have Rust.

I think that actually speaks to Joel's point. None of those were rewrites.

Firefox started as a fresh UI reskin for the old browser interface, and indeed continued as "mostly a skin" for years (incidentally, so did Chrome).

(You can still get the non-firefox skin incidentally, it's "Mozilla Seamonkey")

Then the Rust rewrite. Rust was a hobby project, and they rewrote layout engine interface, and nothing more than that. Then CSS.

Now it's an HTML parser, a layout engine, a parallel CSS engine, and a GPU webpage renderer (still "missing"/non-rust are 2d compositing and javascript). Each of those components replaced another in a working version and there were at least beta versions of firefox of all the parts.

You don't know what we would have instead.

Potential is worthless. We have Rust, we don't have what might have been produced had Rust not happened, and as far as I know, no one is working on that hypothetical product.

I live by that quote every day, but it's not a silver bullet.

It isn't, but in twenty years getting paid to write software I have far more regrets where I rewrote and shouldn't have, than where I should have rewritten and didn't.

If you're Google and you have people with these abilities kicking about, it's probably not a crazy investment to see what happens. We've got a HN story elsewhere in the list on post-quantum key agreement experiments in Chrome, again there's a fair chance this ends up going nowhere but if I was Google if throw a few resources at this just in case.

But on the whole I expect Fuchsia to quietly get deprecated while Linux lives on, even if there's lots to like about Fuchsia.

> post-quantum key agreement experiments in Chrome

Link for reference: https://news.ycombinator.com/item?id=16811554

you usually get it right on the second time. only hope the first dont get too popular.

or run the entire business (when it works) without which the whole company would grind to a halt.

A rewrite made no sense to me since I'd end up maintaining version A alongside version B with B constantly lagging A unless I severely restricted the scope of B in which case it'd be an incomplete (though better written/more maintainable A).

Instead I went the isolate (not always easy), shim, rewrite, replace, remove shim approach.

It does feel a bit like spinning plates blindfold sometimes in the sense I'm always expect to hear a crash.

So far I've replaced the auth system, the reports generation system, refactored a chunk of the database, implemented an audit system, changed the language version, brought in proper dependency management, replaced a good chunk of the front end (jquery soup to Vue/Typescript), rewritten the software that controls two production units and implemented an API for that software so that it isn't calling directly into the production database.. and done it without any unplanned down time (though I'm still not sure how - mostly through extensive testing and spending a lot of time on planning each stage).

It's slower because I have to balance new features against refactor time but I have management buy-in and have kept it, mostly through been extremely clear about what I'm working on and what the benefits are and have built up some nice momentum in terms of deploying new stuff that fixes problems for users.

The really funny part is that even though I'm re-factoring ~40% of the time I'm deploying new features faster than previous dev who wrote the mess...because I spent the time fixing the foundations in places I knew I'd need for new features going forwards.

In my experience the second time leads to architecture astronautics... third time is when you get it right.

Althought in OS space one might argue that second generation of time sharing OSes (TOPS-10, ITS, MCP...) got more things right than are right in Unix and such.

Perhaps I'm subject to a giant whoosh here, but this subthread is recapitulating The Mythical Man-Month piece by piece.

Reinventing well explored areas of software engineering from first principles!

I like the term "architecture astronautics". There is probably a joke hiding somewhere in a plain sight about "Plan 9" wrt Unix...

For OS it means that you should pick one abstraction for process state and one abstraction for IO and in fact you can have same abstraction for both. In this view Plan 9 makes sense while modern Unix with files, sockets, AIO, signals, various pthread and IPC primitives and so on does not (not to mention the fact that on every practical POSIX implementation various such mechanisms are emulated in terms of other synchronisation mechanisms)