Comment by StillBored
4 years ago
Thinking about this more, I wonder if you can predict whether a software project is "failing" by the amount of code that is getting deleted early on.
I've been part of a half dozen or so successful medium->large scale projects, and we never really deleted large parts of the code base. The small teams bootstrapping them had a pretty clear goals of where they were going sufficiently to build a reasonable scafold early on to get somewhat working prototypes. Then as the project took shape things were fleshed or refactored far more than they were thrown away.
OTOH, projects i've seen fail frequently had core pieces rewritten on a somewhat regular basis.
Which if you think about it in the sense that every time a chunk of code is wholesale replaced, that is X man hours of effort flushed down the toilet. Few startups can afford engineers to be working on things which don't go towards the bottom line.
AKA if you have 6 engineers, and on average are replacing 25% of the code base a year, that is the equivalent of just throwing away 25+% of your runway every year. With the team communications overhead/etc I could totally see that it might be possible to never actually make forward progress even though the amount of code being thrown away isn't >50%
The amount of code written isn't static, and doesn't map neatly to "amount of developer effort."
If everything you write has to be "perfect" the first time around, you'll write a fraction as much as if you're willing to build 3 things (either now, or in the future), and take whichever works out the best. It might take more time, or it might take less time.