4 ms·
right/wrong isn't the best mindset here. Code that sits in production working successfully for 6 months only to be replaced is still good code. If something w
by P5fRxh5kUvp2th 4y ago
right/wrong isn't the best mindset here. Code that sits in production working successfully for 6 months only to be replaced is still good code.
If something works for decades and then has to be replaced due to scale, that's a good problem to have. The unwillingness to replace things is where it all goes awry.
OTOH, wanting to _rewrite_ should almost always be told no.
- raffraffraff 4y agoI completely agree. But I also think that these problems never emerge in a big-bang way. By year two, or engineering hire #30, or some other heuristic, you should probably be replacing some of that stuff, refactoring other stuff, and certainly thinking about refactoring teams or hiring to fill specific functions that didn't need to exist at the start. There were so many red flags at that company, and inability to scale was just one, for sure. But these things sometimes come as a complete package. I think my problem with the article is that it thinks it's selling some generically applicable advice. But the wrong type of company with inexperienced engineers can take the wrong message from that article and totally fuck up an otherwise promising product.