9 ms·

What the author calls the product model is just capitulation. There's no agreed-upon requirements and no scope. Each product thus occupies the team in perpetuit

What the author calls the product model is just capitulation. There's no agreed-upon requirements and no scope. Each product thus occupies the team in perpetuity. That's obviously bad for business. I would argue that this model does describe maintenance, but a very bad form (due to the permanent addition of ill-fitting new features to justify the expense). In fact, I think that scrum's failure showed us that projects (what scrum apologists try to disregard as "waterfall") are the way to develop software. Iterations are the way to maintain it. One can put small features into the latter, but everything that's large or has business value deserves a project. You don't know the requirements yet? Then go get them before we start development! Note that projects don't need to be long and projects can easily hang onto an established agile maintenance process, e.g., for releases and other infra. But they need to be planned properly, have an agreed-upon scope and don't need to fit into arbitrary sprints.

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.
- 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.
jbmsf 4y ago
IMO, you need multiple models. The product model (or the "this team owns X" model) force a commitment to an area of work that doesn't always align with business needs. The project model is terrific for aligning people across skill sets, but doesn't do as well for ongoing work and tends to push staff from project to project (vs building deep experience), which can work well for generalists but not for everyone. I see the actual problem being that management is rarely simultaneously deep enough and strong enough to make the right choices around work organization so everything just defaults into hierarchies.
- makeitdouble 4y ago
  To note, "this team owns X" still has the team justify a budget or even its existence when push comes to shove. For instance if there was a “blue check” team of 3 people at Twitter, they’d have a hard time justify keeping the team 100% committed to it for years after the feature is released even if there is some small amount of ongoing work needed. Looking at estimated output vs the costs, they’d probably hibernate the team most of the time, as you do with projects basically.
BarryMilo 4y ago
If your core business is software, you should always have people working on software. You don't stop improving things once they are built because that's how you fall behind competitors, whether improving means maintenance or new features or a mix of both depends on having a good PO. If your core business isn't the software you're building, I tend to agree, but then building instead of "buying" would usually be a mistake.
- xwolfi 4y ago
  The core business is rarely the software. We're not all lucky to work at Jetbrain or Atlassian, some of us work at banks, search engines, social networks, marketing web agencies and stuff like that. And buying is impossible in a lot of cases: if we're gonna be differienciating vs the competition, we wont use an off the shelves software, and sometimes the clients want customization so complex, we could have bought the thing and still need a big team to customize it. I think the guy is basically saying projects need to come back, which I can accept but then we need to know: are deadlines good or bad ? is the client supposed to invest his time in the product or wait for completion ? can requirement be known before progressive iterations have shown a building skelleton to the client ? are developers wasting more time waiting for project design completion or fitting arbitrary scrum sprint scoping ?
sanderjd 4y ago
> You don't know the requirements yet? Then go get them before we start development! Couldn't really disagree with this more. Sure, don't start development before you know any requirements. But also don't wait to start development until you (think you) know all of the requirements.
- lionkor 4y ago
  Why not?
  - dtauzell 4y ago
    Often times customers don’t know what they want until you start to build it.
  - sanderjd 4y ago
    For the same reason that any other exercise in predicting and future is foolish.
tiku 4y ago
You can plan all you want for the first release, but as soon as users start using it there will be changes. If you want to make that a new project with planning that is up to you, but that fact will always continue. Release, change, users demand new changes etc. And that is so true. I've never had a project that was truly finished, also because i suggest new features, especially when I see how they use it. The client doesn't know what is possible, we need to understand their business.
- hunter2_ 4y ago
  There are projects (defined end), and there are programs (indefinite). Sounds like most computer programs are, oddly enough, the latter.
tcmb 4y ago
I think it's worth mentioning the Cynefin model here [1]. Both approaches can work, getting requirements up front can be the right approach for a well-know domain, but often times it's better to treat requirements analysis as a discovery that is ongoing during development. For the latter case, classic project management simply leads to failure and it needs iterative development with tight feedback loops. [1] https://en.wikipedia.org/wiki/Cynefin_framework https://en.wikipedia.org/wiki/Cynefin_framework
rightbyte 4y ago
> In fact, I think that scrum's failure showed us that projects (what scrum apologists try to disregard as "waterfall") are the way to develop software. Ye I have come to this conclusion too. I am not even reading "waterfall" as a pejorative anymore after all the agile I have had to endure. "Every time I hear about software maintenance as a distinct activity, I cringe." The author seem to suggest that never ending agile grind is the way to go and that programs can't be more or less done. Maybe he is doing Cloud™ stuff SaaS, where ongoing costs are a feuture not a bug.

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.
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.

jbmsf 4y ago

IMO, you need multiple models. The product model (or the "this team owns X" model) force a commitment to an area of work that doesn't always align with business needs. The project model is terrific for aligning people across skill sets, but doesn't do as well for ongoing work and tends to push staff from project to project (vs building deep experience), which can work well for generalists but not for everyone. I see the actual problem being that management is rarely simultaneously deep enough and strong enough to make the right choices around work organization so everything just defaults into hierarchies.

makeitdouble 4y ago
To note, "this team owns X" still has the team justify a budget or even its existence when push comes to shove. For instance if there was a “blue check” team of 3 people at Twitter, they’d have a hard time justify keeping the team 100% committed to it for years after the feature is released even if there is some small amount of ongoing work needed. Looking at estimated output vs the costs, they’d probably hibernate the team most of the time, as you do with projects basically.

BarryMilo 4y ago

If your core business is software, you should always have people working on software. You don't stop improving things once they are built because that's how you fall behind competitors, whether improving means maintenance or new features or a mix of both depends on having a good PO. If your core business isn't the software you're building, I tend to agree, but then building instead of "buying" would usually be a mistake.

xwolfi 4y ago
The core business is rarely the software. We're not all lucky to work at Jetbrain or Atlassian, some of us work at banks, search engines, social networks, marketing web agencies and stuff like that. And buying is impossible in a lot of cases: if we're gonna be differienciating vs the competition, we wont use an off the shelves software, and sometimes the clients want customization so complex, we could have bought the thing and still need a big team to customize it. I think the guy is basically saying projects need to come back, which I can accept but then we need to know: are deadlines good or bad ? is the client supposed to invest his time in the product or wait for completion ? can requirement be known before progressive iterations have shown a building skelleton to the client ? are developers wasting more time waiting for project design completion or fitting arbitrary scrum sprint scoping ?

sanderjd 4y ago

> You don't know the requirements yet? Then go get them before we start development! Couldn't really disagree with this more. Sure, don't start development before you know any requirements. But also don't wait to start development until you (think you) know all of the requirements.

lionkor 4y ago
Why not?
- dtauzell 4y ago
  Often times customers don’t know what they want until you start to build it.
- sanderjd 4y ago
  For the same reason that any other exercise in predicting and future is foolish.

tiku 4y ago

You can plan all you want for the first release, but as soon as users start using it there will be changes. If you want to make that a new project with planning that is up to you, but that fact will always continue. Release, change, users demand new changes etc. And that is so true. I've never had a project that was truly finished, also because i suggest new features, especially when I see how they use it. The client doesn't know what is possible, we need to understand their business.

hunter2_ 4y ago
There are projects (defined end), and there are programs (indefinite). Sounds like most computer programs are, oddly enough, the latter.

tcmb 4y ago

I think it's worth mentioning the Cynefin model here [1]. Both approaches can work, getting requirements up front can be the right approach for a well-know domain, but often times it's better to treat requirements analysis as a discovery that is ongoing during development. For the latter case, classic project management simply leads to failure and it needs iterative development with tight feedback loops. [1] https://en.wikipedia.org/wiki/Cynefin_framework https://en.wikipedia.org/wiki/Cynefin_framework

rightbyte 4y ago

> In fact, I think that scrum's failure showed us that projects (what scrum apologists try to disregard as "waterfall") are the way to develop software. Ye I have come to this conclusion too. I am not even reading "waterfall" as a pejorative anymore after all the agile I have had to endure. "Every time I hear about software maintenance as a distinct activity, I cringe." The author seem to suggest that never ending agile grind is the way to go and that programs can't be more or less done. Maybe he is doing Cloud™ stuff SaaS, where ongoing costs are a feuture not a bug.