[Xylakant]

> the average developer spends 42% of their work week on maintenance

Apart from the big question of where that number is from - How is that even a "bad" thing?

I've been on projects where about 100% of the work was maintenance. The app was done. It provided value. Things broke, bugs were uncovered, but the cost of maintaining the app was far eclipsed by the cost of maintaining it.

It's one of the things I hate about software development - every other industry accepts that things require maintenance and that spending on maintenance is a hard requirement to keep the thing you invested tons of money in running. Only software development seems to believe that anything, anywhere reaches a magic state of "done" and will never need to be touched again. And that the only thing that adds value is adding new features.

[carlmr]

>Only software development seems to believe that anything, anywhere reaches a magic state of "done" and will never need to be touched again.

The problem is the mental model. There is a state of "done" for a lot of software. But it subsequently becomes "undone" due to outside factors.

There's no bearings, gaskets and lubricants that need maintenance. The software stays the same. So why would the software need maintenance.

Maintenance in software is because software runs on hardware. Hardware gets updates, and then the software needs updates to match.

Maintenance in software is because software runs on a changing OS.

Maintenance in software is because software interacts with other software that changes.

I think it's this lack of mental model of _why_ software needs maintenance, that it's not planned for.

[WorldMaker]

I wonder how much of "tech debt" would be easier to explain to certain business processes if better reframed under a "bearings, gaskets, and lubricants" model? We don't always have the engineering tools to predict strong "wear and tear" models of such things in software like civil and mechanical engineers have for common bearings/gaskets/lubricants, but on the other side we are also maybe closer than ever to having some baselines: most modern OSes now experience major changes once every 6 months, often with alternating (1 year) "LTS" releases; most modern tools and frameworks follow similar 6 month patterns. The big unfortunate bit is that most of those timelines don't align, but in general "needs to be 're-oiled' once ever 6 months" is starting to be the regular view of things.

(The other thing that this framing calls to mind is that a company doesn't usually send a civil or mechanical engineer to do the general maintenance checks, they first send a cheaper mechanic or other equivalent laborer. This is both where the analogy partly falls apart because not all software maintenance tasks in these 6 month timeframes are "easy"/"trivial" and sometimes need massive software engineering work, and also where we again maybe see hints that in some ways the software industry still maybe needs more of a better defined engineer/mechanic split than it has today.)

[carlmr]

>We don't always have the engineering tools to predict strong "wear and tear" models of such things in software like civil and mechanical engineers have for common bearings/gaskets/lubricants

Because it's not wear. Wear can be measured. Wear is predictable. This again comes back to the mental model.

>most modern OSes now experience major changes once every 6 months, often with alternating (1 year) "LTS" releases

For the OS, this is a fair point. Maybe it should be mandatory to plan for OS updates, which often cause a host of issues.

>some ways the software industry still maybe needs more of a better defined engineer/mechanic split than it has today

I think the reason we don't have a proper split here, is because a split here isn't really possible. Maintenance work _is_ engineering work, you need good judgment to decide whether a dependency update is ok.

A proper test suite can help make the maintenance easier. But there's no mechanic equivalent, since there's not necessarily modular parts to be replaced when interfaces change.

I think all in all we need to move away from engineering analogies. SW engineering is different enough that these analogies do more harm than good. And in the end we should have the self-confidence to ask our managers to understand software as its own discipline.

If a manager doesn't understand what they're managing without heavy-handed analogies, they are in the wrong position.