6 ms·

At the software company where I work, I have seen the defects and half-baked implementations go by for years. Meanwhile, it's new features that development talk

At the software company where I work, I have seen the defects and half-baked implementations go by for years. Meanwhile, it's new features that development talks about the most. Recently it dawned on me that they profess to use the "agile" methodology. So now I wonder... Where does maintenance fall in the agile methodology? Am I mistaken that the balance of it's focus is squarely on development rather than sound design / correct implementation?

RangerScience 7y ago
Maybe the issue is in use of the word "maintenance"? Sure, it's fixing things that break as things are used, but it's not like it's replacing something that gets worn out with exactly the same thing, or cleaning, or IDK enough about what actually goes on for physical plant maintenance. Things like that do exist - log rotation, restarting processes / servers because of memory leaks that aren't worth tracking down - but, mostly, seems like software "maintenance" is more like post-release iteration cycles. Some of these are about the pure tech ("here's a consequence to this design when under use that was not anticipated / handled"), others are product design ("turns out it needed to do something a little bit differently") or additional features necessary to make something useful, or just additional features to make it more useful. Or, you know, it was just built wrong the first time. Seems like all of those situations are actually just more of the same iteration cycles as during development, we just call them "maintenance" for some reason. (well, except that maybe they needed information and observation that are only available once it's under use...)
deleted 7y ago
[deleted]
bigbluedots 7y ago
Agile software development frequently focuses on delivering a set of minimal features, i.e. an MVP. Too often that approach results in software that's poorly designed and implemented, immediately needing a huge refactor in order to get anywhere near being maintainable.
- adrianN 7y ago
  That is actually by design: http://wiki.c2.com/?PlanToThrowOneAway http://wiki.c2.com/?PlanToThrowOneAway
  - bigbluedots 7y ago
    Ideally, yes. Frequently the refactor never happens, though - so new features are repeatedly bolted onto the MVP.
indeyets 7y ago
Agile is about gradual increases of business value. So, as long as maintenance lowers further costs it is a proper aim. Unless there's something else which can bring more value earlier. For some businesses maintenance time never happens. For some it is an important stage before moving to the next iteration of new features. For some it is a daily process with dedicated teams. Every case is different. Agile is about practical agility :)
goto11 7y ago
IMHO there should be no distinction between maintenance and new development. In agile you don't really have "green field" development, since development is iterative. Except for the first week, you are always modifying an existing running system.
baq 7y ago
i'll quote the last three sentences of the article: "In the agile world, success is all about business value - regardless of what was written in a plan months ago. Plans are made, but updated regularly. They guide decisions on what to do next, but are not used as a success measure." so, answering your question with that in mind, the focus should be on business value. does maintenance provide business value? do new features?
- tremon 7y ago
  does maintenance provide business value? do new features? Yes, and yes. In a mature company, maintenance provides more business value than new features. To list some of the maintenance activities: - incident response. It is not uncommon for a company to have losses in the tons/hour or millions/hour if the primary process has a malfunction. - organizational changes. No software exists in isolation; changing requirements in a connected component may require changes in your software component too. Developers may think this kind of work is feature development, but from a business point of view, it's simply maintenance. Because of the dependency by other parts of the company, this kind of work usually has stricter deadlines than "new features". - Predictive maintenance. Identify weak points in the current setup, and isolate of strengthen them before they cause an incident. This includes evaluating technical debt. The value to the business is in risk minimization, and the rationale for this kind of work is predicated on proper risk accounting. These requirements and processes are part of any proper engineering discipline; these are not marginal issues.
  - goalieca 7y ago
    The trick is tempering those values of continuing to make money vs chasing down growth and new sales. With agile you’re always focused on short term. The next few sprints.
- equalunique 7y ago
  I'm just a support person, but it seems to me that it doesn't. At least, not directly. If it did, then development would be focusing on it. Why not? Because the customer already paid. Because Dev wants to focus on getting new customers instead of catering to the ones who have already forked over the money. "What do you mean feature X isn't working for the customer? It's working for us in our lab. Anyway, we're all focusing on getting new feature Y working in our lab now." - This is the attitude I am sensing below the surface. It's frustrating.

RangerScience 7y ago

Maybe the issue is in use of the word "maintenance"? Sure, it's fixing things that break as things are used, but it's not like it's replacing something that gets worn out with exactly the same thing, or cleaning, or IDK enough about what actually goes on for physical plant maintenance. Things like that do exist - log rotation, restarting processes / servers because of memory leaks that aren't worth tracking down - but, mostly, seems like software "maintenance" is more like post-release iteration cycles. Some of these are about the pure tech ("here's a consequence to this design when under use that was not anticipated / handled"), others are product design ("turns out it needed to do something a little bit differently") or additional features necessary to make something useful, or just additional features to make it more useful. Or, you know, it was just built wrong the first time. Seems like all of those situations are actually just more of the same iteration cycles as during development, we just call them "maintenance" for some reason. (well, except that maybe they needed information and observation that are only available once it's under use...)

deleted 7y ago

[deleted]

bigbluedots 7y ago

Agile software development frequently focuses on delivering a set of minimal features, i.e. an MVP. Too often that approach results in software that's poorly designed and implemented, immediately needing a huge refactor in order to get anywhere near being maintainable.

adrianN 7y ago
That is actually by design: http://wiki.c2.com/?PlanToThrowOneAway http://wiki.c2.com/?PlanToThrowOneAway
- bigbluedots 7y ago
  Ideally, yes. Frequently the refactor never happens, though - so new features are repeatedly bolted onto the MVP.

indeyets 7y ago

Agile is about gradual increases of business value. So, as long as maintenance lowers further costs it is a proper aim. Unless there's something else which can bring more value earlier. For some businesses maintenance time never happens. For some it is an important stage before moving to the next iteration of new features. For some it is a daily process with dedicated teams. Every case is different. Agile is about practical agility :)

goto11 7y ago

IMHO there should be no distinction between maintenance and new development. In agile you don't really have "green field" development, since development is iterative. Except for the first week, you are always modifying an existing running system.

baq 7y ago

i'll quote the last three sentences of the article: "In the agile world, success is all about business value - regardless of what was written in a plan months ago. Plans are made, but updated regularly. They guide decisions on what to do next, but are not used as a success measure." so, answering your question with that in mind, the focus should be on business value. does maintenance provide business value? do new features?

tremon 7y ago
does maintenance provide business value? do new features? Yes, and yes. In a mature company, maintenance provides more business value than new features. To list some of the maintenance activities: - incident response. It is not uncommon for a company to have losses in the tons/hour or millions/hour if the primary process has a malfunction. - organizational changes. No software exists in isolation; changing requirements in a connected component may require changes in your software component too. Developers may think this kind of work is feature development, but from a business point of view, it's simply maintenance. Because of the dependency by other parts of the company, this kind of work usually has stricter deadlines than "new features". - Predictive maintenance. Identify weak points in the current setup, and isolate of strengthen them before they cause an incident. This includes evaluating technical debt. The value to the business is in risk minimization, and the rationale for this kind of work is predicated on proper risk accounting. These requirements and processes are part of any proper engineering discipline; these are not marginal issues.
- goalieca 7y ago
  The trick is tempering those values of continuing to make money vs chasing down growth and new sales. With agile you’re always focused on short term. The next few sprints.
equalunique 7y ago
I'm just a support person, but it seems to me that it doesn't. At least, not directly. If it did, then development would be focusing on it. Why not? Because the customer already paid. Because Dev wants to focus on getting new customers instead of catering to the ones who have already forked over the money. "What do you mean feature X isn't working for the customer? It's working for us in our lab. Anyway, we're all focusing on getting new feature Y working in our lab now." - This is the attitude I am sensing below the surface. It's frustrating.