Hacker News Reader

Comment by theamk | Hacker News Reader

No everything needs "team constantly working on code". For example few years ago I wrote a project which takes data from one internal service, parses it, does some processing and puts it into a different internal service. This code has been running 4 times per day ever since. I don't touch it much anymore, except few times per year data formats change, I get a failure alert, and come back to it and fix the parser.

This code is in 100% maintenance. It is done - the existing functionality works reliability, and while I can think of some new features, I have no intention to add them as I am busy with other things which are more interesting and important.

Does it take me longer to fix bugs because I don't work on code daily? Probably. Would it be better (for my happiness or for business) if I start adding features people don't care about to maintain "connection with old code"? Nope.

View on HN

I feel like this is a false dichotomy in the real world anyway. At almost every agency I have worked for we have had both types of clients, and a spread inbetween.

Some are on retainers for ad-hoc support, some are under constant feature development as that is what the business demands, and some we put together and handover to the client complete per a spec.

We don't even use scrum/agile on every project, some just have really light weight agile scaffolding, some we do waterfall if it's small and the client doesn't want to participate in the goings on. It isn't one size fits all in software dev, clients have various situations and expectations you have to meet.

It's all about framing--one could say that adding a new format is a new feature and not maintenance just as easily as saying it is maintenance. The problem with calling it maintenance as the author points out, is that people don't understand what that means unless they write software.

So what you're saying is that, except for all the times you come back to work on the code because something broke, it works reliably? Nothing about the parser could be improved so that it doesn't break on data format changes? Nothing could be improved such that instead of alerting you to failures, it could be pro-actively adjusted to accept new formats before something fails?

A parser which does not break on data format changes is called "non-validating parser", and I am not a big fan of those. I think I can do better for my downstream consumers.

Let me give a hypothetical example: in report FOO, field "Secondary Record" used to contain record number but now it's something else. Should the parser change output type to string? Or try to see if there is a record number somewhere in that string and return it? Or just pretend that this unparseable field does not exist? In my opinion, all of those options are terrible. The parser should stop parsing and alert human maintainer (me). A human will look at new data and decide what to do with it - maybe change the output type, or maybe there is now a record title as well which needs to be handled separately.

As for "pro-actively adjusted" -- well, that would be great, but the data comes through a long chain of services, and while each individual one has tests, there is no overall test for the whole chain. Could I make one and hook it up to each team's CI, so that parser never fails? Sure, but the service is in maintenance mode, so I am not going to do it.

Right now the downstream consumers are OK with the fact that sometimes data stops updating and they have to live with the stale data until I fix the parser. If they ever want more, great! We can set up the project, decide a priority, allocate time (mine or someone else's) and do it. But until this happens, the project is in maintenance mode.

What if the systems they are building provide more business value than minor improvements to a system that functions 95% of the time in a given year? That work to fix it is maintenance and you might be able to argue that given some timeline there’s a break even for the time investment for an improvement, there’s also opportunity cost associated with it.

There is a ton of software that is less a true product and more an integration of systems that only gets improvements and updates when things break. That’s maintenance and you weigh when to make larger changes against what’s valuable to the business, how much toil is associated with it, impact on team morale, etc. If you don’t you’re just making uninformed decisions for the sake of some fuzzy metric representing how connected to code you are.

From my point of view discussion is about what was written in the article: "project", "product" or a "system". Which for me requires team of developers, QA, business analysts and cannot be grasped by a single developer.

I also have small tools that can run after 5 years but I don't see these as interesting argument in the context of article.

Reply on news.ycombinator.com