3 ms·
That's a short term view. Any system you build inhouse has to be maintained until you replace it, and often the longer it remains in place the harder it is to d
by onion2k 8mo ago
That's a short term view. Any system you build inhouse has to be maintained until you replace it, and often the longer it remains in place the harder it is to do that. You might save a small amount of cash (which might be important at the time tbf) but you're creating a major headache for later. Legacy code is debt, and that includes all your code. It's also a huge problem if the maintainer leaves because typically those small systems are owned by an individual dev who set it up in the first place.
Everyone who founds a company needs to remember that they're building a system of systems that all interact and influence each other, and you have to balance short term cash flow against long term strategy.
- PacificSpecific 8mo agoI don't understand why you appear to be downvoted for this (your comment is faded at the time I'm reading this). It sounds like a perfectly reasonable take. I've certainly inherited and also caused these problems in my younger years.
- aleph_minus_one 8mo ago> It's also a huge problem if the maintainer leaves because typically those small systems are owned by an individual dev who set it up in the first place. It's not uncommon that this maintainer actually wants to get away from maintaining this code, and would actually be quite willing to teach some successor how everything works. The problem is that it is often hard to find someone who is similarly passionate about this system (often the system only keeps working because the original maintainer invests a lot of energy into keeping it alive), and is thus brutally willing to learn this system inside out. You can't force this mentality from above: either a suitable programmer has this mentality or he is typically not suitable.
- onion2k 8mo agoTrading one single point of failure for a different single point of failure is never the answer.