Hacker News Reader

Comment by david-gpu | Hacker News Reader

Can you elaborate on this part? I am trying to understand.

> in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place

Wouldn't that imply that rewriting a mature codebase from scratch would take ten times less effort than reading and maintaining it?

I only saw two instances where (different) management approved a complete rewrite of a working product and in both cases it turned out to be a disaster, because it is easy to severely underestimate how much effort it will take to match the features, quality and performance of the old codebase. I suspect it is almost universally better to refactor the old codebase incrementally.

Based on that, I take that you mean something else and I didn't get your point.

View on HN

Absolutely no.

If a line of code belongs in a project with one file and a main() function, the presumption of impact of that code line on overall code paths is trivial.

If that line of code belongs in a library procedure used by a million LOC project, presumption cannot be done if you don't the project internals and tooling.

Rewriting entire systems or frameworks because one thinks that it's hard to implement a certain class of features is almost always a recipe for disaster.

OP said “writing it in the first place” not “rewriting”

But I agree that their numbers don’t really make sense. Software dev is hard to quantify like that.

> OP said “writing it in the first place” not “rewriting”

They did, but how is that significantly different?

Every line of code in the first implementation is there for a reason -- it has an implicit history, and implements a requirement. If that requirement is not captured elsewhere, then the prerequisite for /re/writing a system is to read the first implementation, understand the implicit requirements in the code, capture those requirements (or explicitly eliminate them if incorrect), and /then/ start writing version two. So /re/writing a system is a strict superset of both reading a previous implementation and implementing, and is thus harder than either.

Very well put

True.

That said in any non-trivial project, writing in the first place and rewriting aren't too different from each other in practice.

Assuming someone doesn't have the ability to maintain a consistent and always-accurate mental map of tens of thousands of lines of code, most of which they probably didn't write themself and some of which they might have never actually looked at before, they're going to very rapidly reach a point where most of the work involved in adding a new feature consists of reading existing code to understand how it behaves and how the new code needs to interact with it. So the expensive part of adding new code to a work in progress, and the expensive part of rewriting existing code, are more-or-less one and the same.

> So /re/writing a system is a strict superset of both reading a previous implementation and implementing, and is thus harder than either.

As you said, every line in the old product had a reason to be. You can learn that reason in two ways: the way it was done in the first place, or by analyzing the old code. My argument is that the amount of effort required in both cases is in the same ballpark -- it will depend on a number of factors such as the quality and quantity of the documentation and testing in the old product, the availability of people who worked on the first product, etc.

So, no, rewriting a system is not automatically more work than writing the original one. But it is certainly not automatically less work either, and many people make the incorrect assumption that rewriting a system is going to take much less work than fixing the existing one.

Reply on news.ycombinator.com