[HN Gopher] There Is No Software Maintenance
___________________________________________________________________
There Is No Software Maintenance
Author : nikbackm
Score : 35 points
Date : 2023-01-07 20:06 UTC (2 hours ago)
(HTM) web link (henrikwarne.com)
(TXT) w3m dump (henrikwarne.com)
| PaulKeeble wrote:
| The moment a piece of software is released and in users hands its
| in maintenance, which is the fixing of bugs and production
| issues. But that does not mean its also in development, the
| process of developing new features is quite often a distinct
| activity and not something that has to continue.
| mongol wrote:
| I don't think I agree. There are two distinct activities -
| developing new functionality, and keep existing functionality
| going. In an IT organization, you may for example get an incident
| in production, that requires fixing and deploy of a new version.
| That is maintenance.
| weakfortress wrote:
| [dead]
| mjlawson wrote:
| I would argue that this too is part of software development.
| You ought to have a robust process that can accommodate
| hotfixes while minimally impacting ongoing work. That fix
| requires you to get buy-in from all of the right stakeholders,
| and the deployment requires you to follow the same processes as
| the development team.
|
| I'm not sure if I see the value in making such distinctions
| though.
| mongol wrote:
| Yes it is part of software development in a larger sense. But
| there is value in it if you work as a manager. When you
| create your budgets you need to have an idea about how this
| work is split proportionally, because the work affects
| revenue in different ways. From a budget point of view, you
| can see it like: there may not be enough money to fund new
| feature development and the effect of that would be
| unfortunate. But if there also is not enough money to fund
| maintenance, it is worse.
| dimitar wrote:
| I've worked in place where the majority of projects and the
| majority of code went in to maintenance. There could be several
| months or even a year or two of intensive development, with teams
| reaching a dozen or more developers + QA, DBA, PMs, Ops and a
| bunch of people on the client side.
|
| And then those projects passed UAT, then went on production, a
| round of change requests and the teams were disbanded, with maybe
| a single developer giving some of their time to fix a bug.
| Sometimes such project went many months or even a few years with
| no development time spent on them. Some had backlogs of bugs, but
| it was very hard to mobilize resources to fix them. The company
| was chasing new project that were bringing more money, so after
| delivery the old projects had huge opportunity costs, even if
| there were maintenance fees.
| spfzero wrote:
| I would just say that when the effort of fixing bugs,
| refactoring, re-platforming, updating docs, and tweaking
| features, is greater than the effort invested in major changes,
| you're in maintenance.
|
| Most software applications get there. Take your favorite IDE.
| It's in maintenance. Vim and Emacs are in maintenance. Your
| bank's web app is in maintenance. Chrome is in maintenance.
|
| I admit this is somewhat arbitrary, but there are things that you
| do less of, and things you do more of on a lot (most) of
| production applications with users. Sometimes the needed
| functionality target was missed the first time. Maybe the second
| time. Maybe users massively changed their minds. So you might not
| get into maintenance for a long time, but that might be more due
| to a poor understanding of what the market wanted, rather than
| there being no such thing as maintenance.
| emerongi wrote:
| You can think of maintenance as one sub-branch of software
| development, usually containing tasks that do not create
| immediate value for the business, but need to be done to be able
| to add new features. It's also a good way to make it clear to
| non-programmers that a certain amount of time needs to be spent
| on tasks that seemingly do not create direct value. Maintenance
| is a concept that everyone understands and is a good way to
| explain it.
|
| Regarding the project vs product model, it fully depends on the
| business. Venture outside of the SaaS/FAANG/etc type businesses
| that HN seems to focus on and you'll see countless businesses
| that are very happy to just have a project done for X cost in Y
| time. After that, the project goes onto a maintenance contract,
| where the development team is just expected to keep the lights
| on, fix bugs and keep it secure. From my experience, it's a huge
| part of software development, considering the amount of systems
| that exist in this form is only increasing.
| willnonya wrote:
| This is exactly what I was thinking after reading the article.
|
| Projects develop new products but are expensive to undertake.
| The enterprise products that resukt from these projects are
| largely profitable though deployment and maintenance efforts.
| gloryless wrote:
| This is an unhelpful oversimplification. There are lots of tasks
| that are maintenance, and the more code your team has written the
| more these tasks build up. I don't know what motivates someone to
| pretend it is the same as writing new features, but it deals with
| distinctly different risks.
| throwaway_au_1 wrote:
| I think it's sensible to be critical of the language used in
| our craft, especially when borrowed from the more physical
| world, because with it comes the baggage. For example, I have a
| pet peeve with the phrase "use the right tool for the job" used
| in the context of languages/stacks, because languages and
| stacks are more akin to building materials than tools (IMO).
| Selecting a building material and selecting a tool involve
| different considerations, and thought-terminating cliches like
| the above can give a false sense of clarity. So IMO, to look at
| software maintenance as the author has done, I think is fair
| and reasonable, even if just to render obvious that software
| maintenance is a special variety of maintenance that differs
| from most usages of 'maintenance'.
| TehShrike wrote:
| This matches my experience with software development.
|
| I work on business software that serves an industry for at least
| 10 or 20 years, and there is never any end to development. There
| is always value in making the industry-serving software better at
| serving that industry.
|
| Sometimes that means fixing bugs. Often it means tweaking the
| schema to better match real life.
| hyperpape wrote:
| There's a reasonable point in here, that for some companies,
| there is no distinction between maintenance and ongoing
| development. You're just constantly thinking of new features, and
| the work of building those features and changing the way existing
| features work is comingled. In that case, you have no such thing
| as maintenance. This model is probably more common, thanks to the
| rise of SaaS, and automatically updating end-user software.
|
| But sometimes you sell a product, and the product or some
| component of it (perhaps some integration with another tool) of
| it really is in maintenance mode.
|
| You decide that acquiring new customers is unlikely, or not worth
| the cost, and you make the bare minimum of changes necessary to
| keep the lights on. No one touches it for months, and when they
| do, there's a bug fix. Perhaps customers have new ideas for using
| the software, but you're not going to do them.
|
| That's maintenance mode. It still exists. It's not a fun place to
| be, but it's real. It even can be valuable (since fixing the
| occasional bug report can be very low effort, but necessary to
| keep customers around).
| cm2012 wrote:
| A lot of software these days has api dependencies for the
| things it works with, so it stops working if you stop working
| on it.
| Groxx wrote:
| Sure, but this is sort of like saying there is only one
| programming language because they're all turing complete. Code
| produces behavior, and that's the actual goal, so why do we
| bother separating them and talking about it? Produce behavior!
|
| For there not being two distinct phases: well.... it depends on
| how you draw the line. "Prototype works" -> every change after
| that is arguably maintenance, not development, since it _has been
| developed_. What you 're doing is then "just" handling its
| interactions with the real world - roughly equivalent to repair
| (fix bug / replace broken component) and maintenance (prevent
| total failure when one host dies / lubricate parts so they don't
| fail as quickly).
|
| ---
|
| Even if we both stop taking things to absurd extremes: I agree
| things are not "developed" _and then_ "maintained" in most
| modern, always-updating systems, but I can definitely separate
| much of what I do into "development" and "maintenance".
| Development is whatever is focused on getting a thing working.
| Maintenance is whatever is focused on adjusting the system to
| make that development reasonable beyond the minimum hack, or make
| the changes long-term palatable, or updating libraries, or
| enhancing observability to resolve issues faster, or
| restructuring things to make future changes easier, or...
|
| The list of things we do beyond _initial "development" of a
| feature_ is vast, and you can often adjust how much of it you do
| now vs later... but you generally cannot do "some" development
| later. It either works or it doesn't. You have a button that does
| nothing or a button that does something. Sure, you might be able
| to split a feature into MVP and nice-to-have sub-features, but
| you can't say "oh we'll figure out the contents of that if
| statement next month, ignore it for now".
| ebiester wrote:
| Another perspective not mentioned is that there is a real context
| for why the distinction matters in the US. In the US, new
| features can be described as capital expenditures, or CapEx,
| whereas maintaining the fitness of the software is considered
| OpEx, or operational expenditures, and both are taxed
| differently. This matters for public companies.
| dangus wrote:
| I guess this is an interesting thought experiment but by the
| conclusion I felt like it's just splitting hairs on terminology.
|
| I don't really agree that the line between a bug fix and a
| feature request is blurry. Those two activities are clearly
| distinct in my mind.
| seadan83 wrote:
| Bugs of logic omission could easily be argued as feature
| requests. Who is to say that a very poorly written app,done
| cheaply, whether it intentionally omitted proper data
| validation, or whether adding data validation to resolve
| downstream errors is a feature request.
|
| Another example is the classic, "users would never expect it to
| work like this" vs "it was designed to work that way (even
| though it is ass backwards)". Is fixing something to fit user
| expectations a bug fix, or a feature request? It can really be
| that the question hinges on an original design spec, which
| seemingly should not be determining factor (but it is, and who
| knows whether it was just done badly, or done wrong)
| 015a wrote:
| I have had a really frustrating relationship with software
| maintenance in all of the companies I've worked for.
|
| I've always been a strong, strong believer in an analogy like:
| How much time would you estimate that nuclear engineers spend
| operating and maintaining existing reactors, versus building new
| ones? How about public highway departments and building new
| roads, versus fixing or improving existing ones?
|
| No analogy is ever perfect, but the only logical conclusion I can
| reach is that software engineering is a really weird discipline
| relative to practically all of its "we build things that last
| years" peers. Its weird because, well, our organizations in my
| experience chronically under-invest in maintenance then act
| flustered when new developments don't meet deadlines or take
| forever; but its also weird because all of my experience screams
| at me "I'm not even sure if we _know_ how to maintain systems
| well ".
|
| I've seen this in one org (a public company you'd recognize);
| where years ago we had and met lofty goals like "99.999%
| availability"; today its a good month if we hit three-nines, API
| wide. In team meetings with really senior, smart engineers when
| we ask How Can We Improve This, you start observing this learned
| helplessness where they suggest small changes like, you know,
| adding a cache for some external API, or replacing the built-in
| HTTP client with some other one that has a more comprehensive
| knob for timeouts, or whatever. I talk with them privately and
| say: Is this really the best we can do? It isn't; everyone knows
| that; but we will _literally_ never have the product dev time to
| really fix the problem; maybe, taking what we 've learned from
| some old system and building a new one, cut out layers of
| abstraction, reduce and simplify. So instead, we supplement the
| problem with complexity; and the thing we _won 't_ admit is that
| this is like putting a bandaid on a skin tumor; it may improve
| the metrics on the short-term, but ultimately it _is_ more
| complexity, it _is_ more code, and in a lot of cases we 've
| replaced one way that something fails, predictably, with N ways
| it can now fail, unpredictably, hopefully less often.
|
| The other thing that no one will admit is: If the state-of-art
| way to fix something that needs fixed is to "take what we've
| learned from the old thing and rebuild it" (oftentimes, this is
| the best way; but that's another discussion): No one lives
| forever, and No one stays at a company forever. Knowledge is
| Temporary. Through leaking knowledge or increasing scope, taking
| on maintenance today is _almost always_ easier than taking it on
| tomorrow; and it usually leads to productivity boons which
| magnify over time.
|
| I word a lot of that from the perspective of developer
| experience/productivity, but it fits just as well with Security
| maintenance. I'm working alongside a company impacted by the
| recent LastPass breach. They were storing hundreds of internally
| minted JWTs in there like API keys; no expiration, and no way to
| revoke. "We have to rotate these"; well, lets take a look at this
| Jira ticket from four years ago where one of your senior
| engineers who left three years ago said we need to make these
| things expire, or at least add some kind of revocation list (ok,
| never word it like _that_ to people; but that 's what we're all
| thinking). We don't have that; we can build it, but now the app
| has 5000x the traffic and complexity, so it'll take time.
|
| I share this talk by Johnathan Blow [1] all the time, because its
| fantastic and in this case he hits on a really good point: We
| only know how to do things by doing them. If we, as an
| organization, invest 10% of our time doing everything we can to
| keep existing systems running and productive; that may not be
| enough time to even develop the skills to _know_ how to keep them
| running well and highly productive _if_ we could fight for more
| time. One of the phrases I hear all the time, across many orgs:
| "small steps toward improvement". I think people who say that
| have either given up (learned helplessness), and/or they're
| critically unobservant of the inherent entropy of software
| systems. There is, no doubt in my mind, a "rate of decay" of
| every software system; its different for all of them, its
| influenced by factors like product velocity, external
| integrations, language, etc; but they all have it. And if you
| aren't investing _more_ time in maintenance than your system 's
| rate of decay, you're going to cause your People, your Customers,
| and if you're very unlucky (cough LastPass) your Business a lot
| of pain.
|
| But; my special variety of learned helplessness is that I think
| the people in charge of most orgs actually like pain, and like
| inflicting it on others. Most likely something to do with the
| observation that psychopaths and sociopaths tend to rise through
| the ranks a businesses faster than those with empathy.
|
| [1] https://www.youtube.com/watch?v=ZSRHeXYDLko
| twawaaay wrote:
| Software maintenance is what you have to do for it to keep
| working. It is a useful distinction, especially from the point of
| view of management, even if the tools and skills used are the
| same. In many companies, the funds for maintenance might come
| from a different source than developing new features.
|
| One could say that all office workers do the same job -- reading
| text on the screen, clicking with their mouses and pushing
| buttons on their keyboards. But this misses the reasons why
| people are pushing those buttons or clicking things with their
| mouses.
| mongol wrote:
| Exactly. Maintenance is keeping the lights on. As a manager, it
| is the level of budget you can't do without.
| bee_rider wrote:
| They sorta handle this in the end, which I thought was
| thoughtful, since it does contradict their original point a
| bit.
|
| > However, if you consider that the environment the program
| works in can change (library or OS upgrades for example), then
| you could compare this to handling wear and tear.
|
| > There are systems that are maintained only in this sense:
| fixing bugs, and making sure that it can keep running. But I
| would argue that this is a very small part of all software
| development work being done. Furthermore, when it comes to
| fixing bugs, there can be ambiguity. Is this really a bug, or
| is it in fact a request for new functionality? And why fix the
| bug at all, if it has worked up until now, and the only
| objective is to keep the system running. So, in some sense,
| this form of maintenance is also just ordinary software
| development.
|
| I'm not sure what to think about this in particular. A program
| runs on a computer, which has an OS, and over time those OS's
| are updated. Is "make sure it runs on RHEL 9, when it already
| ran on RHEL 8" a development or maintenance task? I would
| characterize maintenance as dealing with the inevitable decay
| of things over time. Technically the computer+RHEL 8+program
| system should still work but of course you probably want to
| benefit from the new development work put into RHEL 9. And if
| you let your OS become too old, it becomes unsupported and
| insecure...
| mongol wrote:
| Where I work, the difference is basically, making things that
| already bring in revenue continue to work = maintenance. It
| is about the decay over time, but also the cost of just
| making business, keeping the lights on. Just as you need to
| pay your cloud bills to keep your service running, you need
| to have a certain amount of developer-hours addressing things
| that do not work perfectly and needs adjustments and fixing.
| For the developer in question it may not matter much, it is
| git branches and continuous deployments just the same, but
| the distinction is not really for the benefit of the
| developer. It is for the manager that can reason about
| different opportunity costs by knowing how much time and
| money maintenance work needs.
| PicassoCTs wrote:
| Softwares state is depending on how close it is to the
| actual/perceived economic hot-loop in the product.
|
| Thats where features grow, were software is properly maintained
| and tested. The further away it is from this route, the more it
| becomes a stagnant resource backwater, until the software - which
| might be alive in other sections, actually starts to die and
| bitrot, basically a forked away stand alone thing, with its own
| library, tucked into a corner, visited only on rare occasions.
___________________________________________________________________
(page generated 2023-01-07 23:01 UTC)