Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The incrementally part is extremely important and often overlooked. I have seen project after project attempt some major big bang rewrite that always takes way longer than expected, delivers less value than promised, and causes problems in areas that used to work fine. We often understand some big picture things better as time goes on but there's a thousand small decisions baked into the existing code that are very easy to overlook

On incremental improvements you should be able to stop what you are doing within a week or two and be ok with leaving the code like that for a long time.



The main value a big bang rewrite has is that for six to eight months the dev team gets a break from being asked a lot of uncomfortable questions. By the time the questions get properly uncomfortable again, you’ve worked there long enough for it to be reasonable for you to leave.

Incremental improvements require more skill. The sorts of skills that make you a better developer. So even though it’s more difficult, it’s much more valuable to all parties for you to attempt it.

The only reason for a rewrite is when you have a language or framework that’s dead, and there are often other dynamics that put you in that spot in the first place.

There are a bunch of common mistakes people make with trees that take years off their life expectancy. The worst guarantee the tree will be dead in twenty years (and potentially dangerous before that). Software has similar phenomenon, on a much shorter time scale.


I am sure there are good reasons for it, the postgres proposal for switching concurrency models[1] comes to mind. I actually just posted this question to see what people come up with: https://news.ycombinator.com/item?id=36646299

My knee jerk reaction to rewrites is so negative I actually would like some counter evidence on when it worked out.

[1]https://www.postgresql.org/message-id/4658520e-5cd0-6242-e54...


We're in the midst of a couple rewrites that are going/have gone well. Perl to golang and angular1 to react.

The common factor is doing it gradually, basically page by page. There is no big switchover, new code goes live as it is ready. We have some very competent people with long tenures which surely helps.


I'm not a usually a huge fan of buzzwords and I usually give trends time to pass before bothering with them but this is an advantage of micro services that I really like.




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

Search: