[username90]

> I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it.

This is almost surely wrong for most developers, or else rewrites wouldn't fail to deliver within the estimated time so often. Rewrites per definition already has a perfect specification in the old code, just write something working the same way using a new architecture. But that is still really hard to deliver apparently.

Of course it could be true in your case, but you can't blame the inability of software engineers in general to estimate tasks on that.

[detaro]

> Rewrites per definition already has a perfect specification in the old code

If the old code is a perfect specification, there is no need to rewrite it, because you already have a code base that performs to specifications.

Less glib, random code is a terrible format for specifications, because it contains lots of things that aren't actually requirements of the specification, but implemenntation details. And a specification that contains lots of specific things that aren't actually part of the specification is not a good one.

[rickbad68]

In other words, a rewrite is never actually that. There should be a better word we use for this, like 'replacement'

[majormajor]

> This is almost surely wrong for most developers, or else rewrites wouldn't fail to deliver within the estimated time so often. Rewrites per definition already has a perfect specification in the old code, just write something working the same way using a new architecture. But that is still really hard to deliver apparently.

This is precisely why rewrites fail!

I've never seen a rewrite where the devs had a perfect understanding of what the old code was doing. They understand the happy path, probably. Not the millions of edge cases through the years.

They only learn the requirements after knocking out the easy stuff and then getting into the gritty bits of bringing over all the edge cases that didn't fit their new mental model easily.

[spyspy]

On the flip side, a full rewrite is really the only way to surface and understand all of those edge cases. People seem to harp on the idea that rewrites are bad, but I find them to be a natural part of the SDLC. It's a way to refresh the mental model for the devs currently working on it, since the original dev(s) probably moved on long ago. Updating the tech or architecture itself is just a byproduct.

[majormajor]

That's an interesting take, and getting that context is valuable, but it seems like there really should be a way to do that that's less disruptive and destructive to "actually being able to deliver new features" than a full rewrite that stops the world for months or longer...

[sreque]

As someone who has argued against a rewrite, lost the argument, and then proceeded to do the rewrite, I would push back strongly on the notion that we have a perfect specification, which is just "do what the old thing did". This specification is woefully incomplete, of course, just as a vague requirements document for a brand new service or product is incomplete.

When someone proposes a rewrite for software, I ask him or her to think critically along the following questions:

1) What is the purpose of the rewrite? What do you hope to accomplish by it? What business objectives are furthered by the rewrite?

2) Explain in detail what is wrong the the existing code base, and why it is untenable to fix those problems piecemeal.

3) Explain in detail how the rewrite will avoid, overcome, or improve significantly on all the problems mentioned in 2).

In my most recent, case, and as I expect in many others, I couldn't convince anyone to engage on any of these questions.

For 1), we were told that the org planned to build significant new features on the product and the rewrite will help. However, the company's priorities changed significantly even as the rewrite was just getting started. By the time I left the company, I was not aware of any short or long-term plans to continue adding functionality to the now-rewritten product.

For 2), the level of detail was along the lines of "the code base is awful. I hate it!" And, that's about it. Question 3) is, of course, impossible to answer if you failed to answer 2).

Failure to be able to answer these types of questions is also in my eyes a strong indicator that you don't understand the existing product very well. And why would we? The existing team that built the thing had all left by that point, which is, in my experience, the norm, not the outlier. It's normal for devs to build something for a few years and then peace out, either via an internal transfer to another team or a new job opportunity.

I believe that much of software is knowledge acquisition, and much of the cost of software maintenance is in dealing with the failure to transfer and maintain acquired knowledge over time. Rewrites can be spurred by ignorance, and that same ignorance can lead to the rewrite taking much longer than expected.

[dalbasal]

I think of it this way. All problems that become sticky problems, got that way by being sticky. Re-writes encounter the sticky problem one way. When the spec is real, the spec is vast. "Do everything GMail does" is a lot of things.

In internal business app teams, the sticky issue is that no one actually understands the business problems well enough to articulate sufficiently. There's usually very little incentive to be the spec person, on either the technical or business side.

It might often be the same underlying issue. The difference with rewrites is that the "conversation" happens within tech teams, no outside player.

[nicoburns]

Rewrites only really have a perfect specification if the original team does the rewrite. Otherwise there are likely all sorts of behaviours that the rewriting team is not aware of.