It's easy to save money on developers, yet very quickly produce a net-negative result for the company.
Sadly, few companies have guardrails to prevent these sort of shortsighted choices. E.g. requiring parallel approval of projects by IT architects (whose existence admittedly carries its own hazard).
I think a lot of this effect is caused by wishful thinking from people embarking on business plans which they would realise are non-viable if they did the accounting properly. People are buying a fantasy instead of an IT system.
And that's not because the guy making it is shit. It's because while he's making it, the market is moving and I'm watching it, and when it moves enough I have to come over to him and tell him to change things.
That's why slow, costly things overrun by more and are later. It's because the world changes, and fast+cheap things are superior because even if they're worse, they exist and can therefore be changed to what the world is.
If you put in the time and pay the money to build an awesome system that is stable and usable for decades, there's only a small chance you'll be rewarded. First because no one notices when software is working. Second because you will probably have moved on to a different role at a different company after your wisdom is confirmed ten years later.
Saving money now is what gets attention.
Undoubtedly this is true, but there's an implication here in this context that somehow on shore, or more well paid developers don't create such technical debt, when in fact they do. It amazes me that I see team after team of competent well intentioned developers create one ball of mud after another. It's striking really.
I have known this as a junior, never really getting to know a technology before hopping to the next one, and I am still having to deal with this now that I have a bit more experience, trying to convince my colleagues not to be so quick to dismiss the modern for the newer.
Sometimes I feel like I do not know what we are doing although being one of the senior members of the team. Stuff quickly snowballs into mud... It's like there is not enough effort or time to deliver functionality while also staving off entropy
It is! But I don't understand... how? How does that happen? You should put good people together and get something good. But it is not always so. Very puzzling to me.
This is like heroin to these corporations. They use Jira and Rally to create a cult of numerology games that reduce tasks to filling time-boxed, random things- to-do. Be sure the Agile coach is drilled in the game and clueless about "technical-things". Add an equally clueless Product Owner whose background is Word and Excel and you'll create the best Big Ball 'O Mud anybody ever wished for.
And if you're running late, add a dozen or so new inexpensive -cough- "developers" from your favorite outsourcing firm.
Fully agree, but the people making the decisions at large corps are not developers, and are just as focused on costs as the Indian outsourcing firms pushing low cost devs. And in turn, those people are pushed by the board to make cost reductions, and board members understand this even less.
As a developer and architect, I've had this discussion many times over my years working in the enterprise space, and it always ended with me throwing my hands up and giving up.