Hacker News Reader

Comment by sirsinsalot | Hacker News Reader

> No engineer is paid extra for keeping the codebase without growing too much.

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.

View on HN

Confirming a hypothesis I put forth in a different comment: Would you say you and your team have ownership of the product?

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.

We do have ownership, and I try and structure the development such that every engineer has ownership, decision making power and accountability. I aim for a flat responsibility structure as much as possible. We have lots of work to do, lots of changes in process and despite the constraints we have a steady stream of features we do add.

The trick is to ensure the culture of solid engineering goes right through the organisation and informs everything from commercial/financial through to QA.

Are you guys hiring. I pride myself on writing short, simple and readable code.

Minimal change, or minimal code? Refactoring code can make code smaller but depends on good testing. Applying minimal changes results in redundant and complicated code, but less likely to break existing functionality.

In the first instance, both. However, i'd take more code that was better reasoned and easily understood over less verbose code that was smaller for smaller sake.

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.

IME this can be hard if built on a platform or dependencies one doesn't control, which is common at early stage companies.

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.

This is true, but in our case all dependencies are vendored and frozen.

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.

What kind of software do you work on? At what company?

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'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 (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.

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.

If it's done by stakeholders, the app will look simple but still be a juggernaut of over-engineering underneath.

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?

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 also I’m a similar situation, but I get the call when the thing has been on fire for a while so it’s a lot easier.

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.

For that to happen, two things must match: a product guy who knows your job and you who know how to make products. It doesn’t even have to be stable/featureless, in my experience. New developers tend to worship some new paradigm that focuses on “how” instead of “what”, which is all paradigms can do. And once they’re in, it goes downhill because the how dominates the what. Add a clueless product guy into the mix and it loses all limits, including budget. In the end they proclaim “software is hard” and move on.

I'm not GP but I'm in a similar situation, and yeah, this is how I do it.

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 and business arguments any new paradigm or random refactoring they want to do. If there is no immediate need, we just skip it.

I'm fortunate enough to be both the lead engineer and the person making product/design/feature decisions with the engineering team.

> I'm not saying this is a common situation, but it certainly isn't rare in my experience.

I think your experiences may be skewed by the position you find yourself in?

Bless you man, you're doing the lords work

It ain't much, but it is honest work ...

... and well paid.

Reply on news.ycombinator.com