3 ms·

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

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.

gombosg 4y ago
Absolutely good points! I used to work in a (Scrum) team where 80% of our projects were in maintenance mode exactly the way you described. It felt horrible to work there as an engineer (at least for me who enjoys creative processes and development). You still get all the meetings, administration, rituals, debates over minuscule stuff - without delivering any customer value. There were entire sprints where most of the team hasn't shipped any useful feature, only fixing cryptic bugs in "other people's code" that nobody really cares about or keeping up with the latest changes in the NIH syndrome-ridden microservice environment. Realizing that such a large organization can't be fixed, I moved over to a different company where the engineering team works more with a "product engineer" mindset. Probably the best decision in my career so far! We're still "maintaining" software, fix bugs and refactor etc., but due to how Shape Up [1] works, creating customer value vs. maintenance is almost always 6 weeks vs. 2 weeks so 3:1. But even for a Scrum team in a large org where some projects are passed around like hot potatoes, I'd never assign more than 50% maintenance mode projects to any team. This may not be the most efficient from the organization's standpoint, but it would probably do wonders for preventing burnout and employee churn. [1] https://basecamp.com/shapeup/ https://basecamp.com/shapeup/
titzer 4y ago
> Chrome is in maintenance. Unfortunately this is not good example, because Chrome undergoes continuous refactoring and is always adding new web features. Even V8, which I worked on for almost 7 years, is definitely not in "maintanence", as JS changed radically in that time and we added the Wasm engine subcomponents. I kind of agree with your other points, but this is really a spectrum. For example, a 115 year old house is in "maintenance mode", yet it needs new insulation, wiring, upgrading the heating/cooling, interior redesign, floors, windows, etc. The truth is that most long-living systems are composed of many different subsystems which run the spectrum from "install once, fix it when it breaks" to constantly being rejiggered.
- spfzero 4y ago
  But I would say, continuous refactoring is maintenance. You would not need to do it unless there was technical debt that had not been addressed in a timely manner. And when you are forced to do development because your underlying platform, i.e. javascript, changes, that's maintenance. You're not adding anything, you're just adapting. Though I concede that to the extent that the JS changes allow new capabilities and you engineer them in, that's a gray area.

gombosg 4y ago

Absolutely good points! I used to work in a (Scrum) team where 80% of our projects were in maintenance mode exactly the way you described. It felt horrible to work there as an engineer (at least for me who enjoys creative processes and development). You still get all the meetings, administration, rituals, debates over minuscule stuff - without delivering any customer value. There were entire sprints where most of the team hasn't shipped any useful feature, only fixing cryptic bugs in "other people's code" that nobody really cares about or keeping up with the latest changes in the NIH syndrome-ridden microservice environment. Realizing that such a large organization can't be fixed, I moved over to a different company where the engineering team works more with a "product engineer" mindset. Probably the best decision in my career so far! We're still "maintaining" software, fix bugs and refactor etc., but due to how Shape Up [1] works, creating customer value vs. maintenance is almost always 6 weeks vs. 2 weeks so 3:1. But even for a Scrum team in a large org where some projects are passed around like hot potatoes, I'd never assign more than 50% maintenance mode projects to any team. This may not be the most efficient from the organization's standpoint, but it would probably do wonders for preventing burnout and employee churn. [1] https://basecamp.com/shapeup/ https://basecamp.com/shapeup/

titzer 4y ago

> Chrome is in maintenance. Unfortunately this is not good example, because Chrome undergoes continuous refactoring and is always adding new web features. Even V8, which I worked on for almost 7 years, is definitely not in "maintanence", as JS changed radically in that time and we added the Wasm engine subcomponents. I kind of agree with your other points, but this is really a spectrum. For example, a 115 year old house is in "maintenance mode", yet it needs new insulation, wiring, upgrading the heating/cooling, interior redesign, floors, windows, etc. The truth is that most long-living systems are composed of many different subsystems which run the spectrum from "install once, fix it when it breaks" to constantly being rejiggered.

spfzero 4y ago
But I would say, continuous refactoring is maintenance. You would not need to do it unless there was technical debt that had not been addressed in a timely manner. And when you are forced to do development because your underlying platform, i.e. javascript, changes, that's maintenance. You're not adding anything, you're just adapting. Though I concede that to the extent that the JS changes allow new capabilities and you engineer them in, that's a gray area.