I have seen low level parts that are managed well, because employees have skin in the game
But I’ve also seen a lot of what this post is talking about
I am the lead because I know, from experience, not to allow this kind of nonsense to happen.
It is only possible because I'm a technical manager myself and I have a very competent (and technical) product manager working with me.
But for every person like me, there are 10 other devs trying to cram every pattern from the GoF book in their corner of the codebase, so I have to spend my scarce time reviewing PRs.
Most of the systems handle complex calculations. The system is a monolith that has been around for 15 years or so.
It isn't cool. It isn't pretty. Lots of it would be better for a refactor, but absolute stability is the goal. Refactoring things may result in long-term cost savings, but with risk. The business has no risk appetite, so it doesn't make sense. If it works, it stays, however ugly and costly.
That isn't to say some things don't get refactored, but there's a strict business case that needs to be met. Usually if the system is under performing, error-prone or end-users want features/performance that can't be accommodated without a refactor.
It's nice. The latest framework isn't being integrated year after year, there's no microservices, nothing fancy.
It's java. It's tested. It works. It makes money. It pays.
Stability is something that must be culturally hammered and enforced by leadership.
Much of the same reasoning and even more extremely applied, is medtech - hence why you see many medical imaging setups still obviously running a version of Windows XP.
The cost (financial, legal, reputation) of certain classes of bugs is so high that avoiding those risks becomes top concern.
One calculation issue, one buggy float operation means millions or billions in damage and the loss of your clients ... never to return ... because your name is tarnished.
I actually think this is _wrong_ and we need better resiliency in finance to being able to roll-back transactions and rewind and replay with adjustments.
Our salary is loosely linked to what percentage of our work is billable (with leniency for inexperienced staff, who aren't expected to be profitable while they're learning their craft).
If you spend three hours figuring out why things fall apart on the 31st of the month... that generally can't be billed to the client, and therefore it's bad for your salary.
On the other hand, if you spend three hundred hours writing tests and implementing an awesome multi-stage deployment process that avoids one production bug a month? Your manager can totally bill that work (with the right client).
If I were a client, I wouldn't want these perverse incentives to exist. I would want a razor sharp focus on _my_ needs, and assurance that _my_ needs are modelled in the billing.
And for that, I would pay more.
... and well paid.
In terms of minimal change, we refactor when there's a clear business case to permit taking on the risk. Otherwise, we make the most minimal, most stable, least risk change to the existing code even if that code isn't optimal/pretty/well-structured/has-errors/...
Like most other engineering in the world really.
Because often the dependencies require surfing latest, or close enough, versions to maintain a secure system or avoid stalls for jumping major versions. Sometimes even core languages and standard libraries may require staying at least near latest versions.
We _do_ have instances where target systems for deployment become ABI/API incompatible with the libraries, which is rare and happens roughly every 5 years.
The project was structured to put stability at the core, rather than being cutting edge.
My Product Manager is competent both in technical and product/design matters and is also able to call BS on complexity for complexity sake. I ensure that the development part is focused.
New developers have to prove with technical arguments any new paradigm or random refactoring they want to do. I'm pretty chill, though.
I think your experiences may be skewed by the position you find yourself in?
That is to say, there isn't one team doing what you're doing and then another separate team trying to graft new features on all the time, is there? Maybe there is, and maybe that causes issues down the line.
The trick is to ensure the culture of solid engineering goes right through the organisation and informs everything from commercial/financial through to QA.
I can’t imagine a software engineer developing an interest defensive software engineering will be very visible until after there has already been a crisis to screw people’s heads on straight.
A lot of people seem to see “Do things that don’t scale” and think that’s a phrase meant for engineering.
I am. I'm paid more than most developers to run a team doing just this. We make minimal change, have an absolutely non-negotiable focus on stability and minimalism and reject any change that isn't absolutely driven by validated majority user need. Even then, the bar is high.
I'm not saying this is a common situation, but it certainly isn't rare in my experience. Software is a vastly wide scope of software types and requirements. I'm paid to be ruthless, and to know what ruthless looks like in terms of delivering consistently without downtime/data loss/critical issues.