Hacker News Reader

Comment by richardbarosky | Hacker News Reader

Insightful. Agree with this take.

Unfortunately, maintainability is simply bucketed as a "non-functional" requirement.

Maintainability (and similar NFRs) should actually be considered what preserves and enables the delivery of future functional requirements -- in contrast to framing non-functional requirements as simply "how" the software must do what it does vs. the "what"/functional requirements that "actually matter".

From that standpoint, if a steady flow of features/improvements is important for a project, maintainability isn't really a non-functional requirement at all, and amounts to being a functional requirement, in practice, over anything except the shortest of time horizons.

View on HN

I've found the first, and most important, step for any team or organisation to eliminate concerns with NFRs, "tech debt", and whatever else it may be called, is to stop giving it a name.

I'm being completely serious. By giving it some kind of distinct name, you are giving license to it being ring-fenced and de-prioritised by someone who doesn't (but, arguably, probably should) know better.

Quality matters. It hits your P&L very quickly and very hard if you don't maintain it. So it is as important as any other factor.

Name it "not done yet." But, yes, very keen observation here.

This is so important. This is your job as a software engineer. It shouldn't exist on a roadmap or get added to tickets. It should just be done in the course of your work.

If it does end up as a ticket that means you did something wrong in the implementation of a feature and that lack of quality got noticed. A business person is not qualified to weigh in on the importance of these things. All they know is "The page needs to load in $time", "The data should stay consistent", ...

You are the one who determines the how and quality maintenance is on you.

I like the idea of not naming it.

I treat it like housekeeping and treat features like hosting a party. Guests/stakeholders are people who want what you can make. The party is the feature they want.

They don't care whether it was difficult or easy for you to clean the house. They just assume keep your own house tidy ... and they know you don't when you only host once a quarter instead of once a month.

They assume you're a functional adult who manages his own space.

Tech debt is like that.

Thus - the business folk don't get a say in whether it's in the sprint - cuz it's not "the party". Instead it's your Scrum Master or whatever saying "hey kids - clean the mirrors and Jane this time you're sanitizing the toilet."

> amounts to being a functional requirement, in practice, over anything except the shortest of time horizons

Right! The unfortunate thing is that many software companies don't seem to think much further than a quarter ahead, not really.

Sure they might have a product roadmap that extends for a year or two into the future, but let's be honest. Often that roadmap is mostly for sales purposes, not engineering planning purposes. Product and engineering will pivot if sales slump. The earlier in the company's lifespan, the more likely this will happen often

However if companies get out of this startup mode then they should start to stabilize... But many don't. They continue this pattern of short sighted short term planning, which means product stability remains a low priority effort.

Ultimately I guess many companies just either do not have the resources to build good software or do not actually care to

Forget the term “non-functional”. Who wants software that doesn’t function? Use Kevlin Henney’s terms: operational and developmental characteristics. Maintainability is a fundamental developmental issue.

The maintenance cost argument cuts both ways. We ran into this building our own project AI moves fast, but the bugs it introduces are weirdly hard to spot. Not the obvious stuff. The logic that looks completely reasonable until three weeks later, when something breaks in production, and you trace it back to a subtlety the AI got wrong. My honest take: AI doesn't reduce maintenance costs, it shifts them. Less time writing, more time reviewing. And reviewing AI code is harder than reviewing human code because it's fluent and confident even when it's wrong. Whether that's a net win depends entirely on how good your team is at reading code vs writing it

AI coding assistants are really good at writing code with subtle errors of the sort humans struggle to notice, even with close and sustained focus.

The review burden scales with the agent's decision space (which almost nobody is doing anything to limit today) and it's a variable you can control. When an agent has a discrete state, a subset of tools it can work with and constraints on the quality of the result the surface area of what could go wrong shrinks in proportion. The article treats this shift as inherent. It's more like we're all surprised pikachu that we gave the agents access to everything and expected it not to happen ever.

Reply on news.ycombinator.com