Hacker News new | past | comments | ask | show | jobs | submit login

Sometimes it's because developers just want to change tech to enhance their cv or keep themselves entertained. That's scary.

Sometimes it's rewritten because it's so unstable because debt wasn't paid off but total cost of writing it twice is much more than paying off as you go along. That's scary too.

I thought this was the old quote Fred Brooks quote, "Plan to throw one away; you will anyway."

Although then you butt up against the "Second System Effect", so you're damned if you do, damned if you don't.

Within consumer tech, it's more like "Plan to throw it all away; you will anyway."

I used to measure code lifetime in half-lives at Google: the half-life of most of the code there was about a year, meaning that after a year, 50% of your code will have been deleted. It's pretty accurate: by the time I left after 5 years, about 97% of the code I'd written had been deleted. Ironically, I'm told that my one contribution (after 10 years) that still exists is an attribute-renaming CL that I wrote over break at a team summit; basically the whole team agreed it was a good idea, we would never have a chance to fix the problem later, so I just went and did it before the framework got too entrenched to change. Meanwhile stuff I slaved over for months, sometimes even stuff that was directly sponsored by a VP (who is no longer there) or got commendations from the CEO (who is also no longer there) was gone within 1-2 years.

In my experience prototypes / proof of concpts always end up in production. Might as well make a half decent first attempt.

Often times if something needs to be rewritten, it means that the feature became popular enough that it needs to scale up. It is not a bad problem to have.

Even well written code might not scale or be flexible to changing requirements. The feature could even be removed. The effort it took paying off tech debt prematurely would have been a waste.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact