[necrobrit]

> It seems to be a necessary evil for a company to grow

Yep, the needs of a company change when and if it grows. Early days, a small team "getting shit done" is probably what you want to find your place in the market, make early customers happy, etc. But as you scale on all axes: time, headcount, headcount turnover, customer count, feature count and so on, that early pile of shit that got done can start to bog you down. Even worse if no one recognises the need to change and continues adding to the pile.

I've seen a few really brilliant engineers struggle with this in various ways: 1. Start hating their job but being confused because they love the company -- not realising that the company has become a very different beast to the early days. 2. Struggling to get out of the "get shit done" mentality and just floundering. Even becoming a net negative contributor in some cases.

Worth remembering this I think in an industry where rapidly changing companies are so common. Your company might be a good fit _now_ but that does not mean it will stay that way!

[xmprt]

I think the biggest issue with the grandparent comment's approach is that it makes things extremely difficult for newcomers as was already mentioned. Turnover is inevitable in an organization and that means that eventually there will be a point where the person who wrote the initial code is no longer at the company. Touching that code is a pretty big liability if no one really understands how it works and that bogs down productivity a ton. Another reason why sometimes rewriting something is the right answer.