Until you have the star developer that starts promising the product manager he can do all the extra features in a week. And then of course none of them actually work decently or at all. But at that point it must be maintained by the whole team anyway.

Well yes, but I have veto power for that reason, as lead engineer.

I am the lead because I know, from experience, not to allow this kind of nonsense to happen.

I'm in the same boat as GP. I work in finance. CTO said he wanted to keep things simple and stable, so I do it.

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.

Am GP, it is finance based, but not commercial finance.

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.

Interesting, I believe there is something to finance that allows or forces things this way. There’s much less fidget spinning and much more business in it for some reason.

Regulations, I’m guessing.

Regulations are a good excuse, but there is still a lot of fuckery in Finance apps, especially in the Fintech space.

Stability is something that must be culturally hammered and enforced by leadership.

Regulations (as sibling comment mentioned) is one aspect, but also the cost of screwing up is real-world. A status quo system that isn’t screwing up has a much higher bar to replace where the risk that the replacement system will screw up.

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.

Regulation and risk. The same applied to government too.

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.

I work at a consulting firm.

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).

I would argue the billing model, client relationship and everything else commercial isn't running effectively at that firm.

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.

Why is the bug fix not billable, but the test writing is?