3 ms·

Bad for business? I think worse for business is not maintained software. When you move devs to another project after 6 months they lose connection with old cod

by ozim 4y ago

Bad for business? I think worse for business is not maintained software. When you move devs to another project after 6 months they lose connection with old code. Fixing anything non-trivial becomes 10x more expensive. When you have team constantly working on code it is a lot easier to have stuff fixed. IMO that is why we see everything moving to a SaaS model. Where SaaS model allows multiple companies to get some software running in perpetuity by essentially sharing cost by paying subscription.

theamk 4y ago
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.
- cratermoon 4y ago
  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?
  - theamk 4y ago
    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.
  - mbernstein 4y ago
    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.
- zip1234 4y ago
  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.
- ehnto 4y ago
  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.
- ozim 4y ago
  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.
makeitdouble 4y ago
> Fixing anything non-trivial becomes 10x more expensive. It’s the same model as car repairs. You can do checkups and small maintenance every month, or have the whole thing checked and repaired when enough time passed or something critical broke. IMO it comes down to wether you can afford for it to break . If it’s a subsystem that can be broken for 2 weeks, regular maintenance might not make much sense for instance.
- barbarbar 4y ago
  Yes it probably can be compared to car repairs. But often the programmers will promise that it will be much better to introduce the new hunken dakser reactivity framework. And this will then continue in the infinite scrum project.

by ozim 4y ago

theamk 4y ago

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.

cratermoon 4y ago
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?
- theamk 4y ago
  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.
- mbernstein 4y ago
  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.
zip1234 4y ago
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.
ehnto 4y ago
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.
ozim 4y ago
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.

makeitdouble 4y ago

> Fixing anything non-trivial becomes 10x more expensive. It’s the same model as car repairs. You can do checkups and small maintenance every month, or have the whole thing checked and repaired when enough time passed or something critical broke. IMO it comes down to wether you can afford for it to break . If it’s a subsystem that can be broken for 2 weeks, regular maintenance might not make much sense for instance.

barbarbar 4y ago
Yes it probably can be compared to car repairs. But often the programmers will promise that it will be much better to introduce the new hunken dakser reactivity framework. And this will then continue in the infinite scrum project.