I think the author is thoroughly immersed in the software development within the IT industry. There, software is your bread and butter. It would be preposterous to even consider stopping to develop software. What else would pay the bills?
If you’ve seen the use of software in the industry outside IT (factories, law firms, stores, etc.) you’d know that software is needed there to solve a problem. The requirements are written, software is developed, and starts to solve the problem it was made for. That’s it. And as long as the requirements don’t change, it’s the change to other parts of the software stack or a vulnerability that prompt software modifications. I’ve seen firmware flashing software for MCUs developed more than a decade ago. When I asked why it’s so “ancient”, I was asked why would there be a need to replace something that has been reliably working for more than a decade?
P.S. “product model” holds no water. A hammer is a product and it does not require “continual development”.
P.P.S. Even in the “IT” software, programs can be “done”. For example, grep, mlocate, rsync. It’s not “a very small part of all software development work”.
I wish more companies were okay with software being “done.”
My biggest complaint with my iPhone is that so many of their UI changes are arbitrary at this point. It’s infuriating to upgrade and find shorcuts and swipes that worked for years are now replaced and changed. It’s not better, but some UI designer or developer needed to justify their salary, so we get an arbitrary change. Like I want to waste my whole life learning and re-learning my telephone UI.
Bit rot is real though, and the amount of work to keep ancient software running is often enormous. Updating software to run without additional issues on newer platforms is often well worth it, in the long run.
By the way, it doesn’t look like grep or rsync are “done”; they both had releases in the last year.
I’m ambivalent. If a tool works and then doesn’t anymore due to, for example, incompatible OS APIs, you have to rewrite it or correct what is wrong.
It will take time, yes, but my opinion is that it will take the same amount of time or less to fix it right now than to have a dedicated team performing incremental updates.
In one case you have 1 dev for, say, a week; in the other case, 1-2 devs intermittently for years.
I can recommend reading https://en.wikipedia.org/wiki/The_Goal_(novel) to anyone interested in understanding the viewpoint of the non-software industry and what prompts them to change something.
I wasn’t entirely compelled by the argument, although I see where the author is coming from. But I did not like the clickbait title.
From the introduction:
Software maintenance is simply software development.
From the conclusion:
So, let’s stop talking about software maintenance is if it were a separate activity. It is not. It is just software development.
According to the author there is software maintenance: it’s the same as (or a subset ot?) software development.
What I didn’t find compelling from the article was the lack of depth. If they are the same, then why not explore it further? Would (or why don’t) developers start to refer to themselves as “software maintainers”, for example?
Anyway, the article is thin and only raises an interesting point of discussion without doing much to answer it, aside from platitudes one might expect from Uncle Bob.
It’s also missing the whole responsibility angle. At least in open source, but probably also in a lot of proprietary contexts, there is one or a small group of “maintainers”; stewards of the project. These people are responsible for creating a roadmap with planned features, reviewing and integrating code submissions from non-maintainers, etc. Maintainers are usually also developers for the project they maintain, but they don’t have to be.
If I start contributing to some project, I am a developer who does software development for that project. I am not a maintainer, as I have neither the privileges nor the responsibilities associated with maintainership.
When we ask questions such as “who is the maintainer of Git” or “who are the maintainers of Linux”, there are clear, unambiguous answers which carry real significance, and it is very difficult from the questions “who are the developers or Git” or “who are the developers of Linux”.
One possible consideration is that software, being formal artifacts, doesn’t actually change with time. Rather, our society is what is changing, and software developers are creating new versions of software over time in order to keep up.
The author goes from one misguided of a spectrum as just a binary - maintenance vs development - to another one - product vs project.
The same way that software can be anywhere along a spectrum of new development and maintenance modes, it’s development can also be in a spectrum of what he describes as product and project mode.
I see in real life a complete and utter disconnect between “We need this feature” and “We made X amount from this feature” and “We spent Y developing this feature”.
When I look at some software systems and try estimate how many real live customers are using certain features… I bet most Phd thesis’s are more widely read, but there is a largish cost in test and maintaining them.
It is often not possible to calculate what that X mount is. Software is bought and used by humans and they are way to fuzzy for that.
In a previous job we had some horribly outdated part in the system that constantly broke and the functionality it provided used only by a few customers that probably only forgot to turn them off. It brought no value. Everyone in the team agreed that it cost way too much time and energy to maintain for what it provided. So we tried to get rid of it.
But that didn’t work. While the features were not very useful in practice, they looked nice in the marketing and helped explaining “the story”. A few sales people claimed it helped selling the product. So the features stayed. Because running an A/B test on that would not have worked.
Sales will always claim they need everything to sell anything, one of the constants of the universe.
We have X&Y, our competitors have X&Y&Z so we must have Z. (Actually we have X&Y&W and they have X&Y&Z, but sales doesn’t really understand what W does anyway., so on the quiet they aren’t even selling that feature)
And in the race for more points on the brochureware, usability and reliability and simplicity is lost.
Products become more complex than mere mortal can understand, and it becomes a market for lemons.
Eventually the market degrades to one premium product almost no one can afford, and one cheap and shitty one that has all the brochure points, but almost non of them are usable or work.
The classic example of this arc was wristwatches.
Eventually, no matter what face and wristband they had, and they had hundreds of different ones, they all had the same shitty core that was fundamentally flawed (too easy to accidentally reset the time).
I wish the effort was poured into simplicity and reliability, and then innovating something new in an adjacent product space.
Products die. If you’re working on a product whose death is scheduled, 100% of the work you’re doing is maintenance. All of that work was done before death was scheduled, therefore all products have maintenance work.
I think the author is thoroughly immersed in the software development within the IT industry. There, software is your bread and butter. It would be preposterous to even consider stopping to develop software. What else would pay the bills?
If you’ve seen the use of software in the industry outside IT (factories, law firms, stores, etc.) you’d know that software is needed there to solve a problem. The requirements are written, software is developed, and starts to solve the problem it was made for. That’s it. And as long as the requirements don’t change, it’s the change to other parts of the software stack or a vulnerability that prompt software modifications. I’ve seen firmware flashing software for MCUs developed more than a decade ago. When I asked why it’s so “ancient”, I was asked why would there be a need to replace something that has been reliably working for more than a decade?
P.S. “product model” holds no water. A hammer is a product and it does not require “continual development”.
P.P.S. Even in the “IT” software, programs can be “done”. For example, grep, mlocate, rsync. It’s not “a very small part of all software development work”.
I wish more companies were okay with software being “done.”
My biggest complaint with my iPhone is that so many of their UI changes are arbitrary at this point. It’s infuriating to upgrade and find shorcuts and swipes that worked for years are now replaced and changed. It’s not better, but some UI designer or developer needed to justify their salary, so we get an arbitrary change. Like I want to waste my whole life learning and re-learning my telephone UI.
Bit rot is real though, and the amount of work to keep ancient software running is often enormous. Updating software to run without additional issues on newer platforms is often well worth it, in the long run.
By the way, it doesn’t look like
greporrsyncare “done”; they both had releases in the last year.I’m ambivalent. If a tool works and then doesn’t anymore due to, for example, incompatible OS APIs, you have to rewrite it or correct what is wrong.
It will take time, yes, but my opinion is that it will take the same amount of time or less to fix it right now than to have a dedicated team performing incremental updates.
In one case you have 1 dev for, say, a week; in the other case, 1-2 devs intermittently for years.
I can recommend reading https://en.wikipedia.org/wiki/The_Goal_(novel) to anyone interested in understanding the viewpoint of the non-software industry and what prompts them to change something.
I wasn’t entirely compelled by the argument, although I see where the author is coming from. But I did not like the clickbait title.
From the introduction:
From the conclusion:
According to the author there is software maintenance: it’s the same as (or a subset ot?) software development.
What I didn’t find compelling from the article was the lack of depth. If they are the same, then why not explore it further? Would (or why don’t) developers start to refer to themselves as “software maintainers”, for example?
Anyway, the article is thin and only raises an interesting point of discussion without doing much to answer it, aside from platitudes one might expect from Uncle Bob.
It’s also missing the whole responsibility angle. At least in open source, but probably also in a lot of proprietary contexts, there is one or a small group of “maintainers”; stewards of the project. These people are responsible for creating a roadmap with planned features, reviewing and integrating code submissions from non-maintainers, etc. Maintainers are usually also developers for the project they maintain, but they don’t have to be.
If I start contributing to some project, I am a developer who does software development for that project. I am not a maintainer, as I have neither the privileges nor the responsibilities associated with maintainership.
When we ask questions such as “who is the maintainer of Git” or “who are the maintainers of Linux”, there are clear, unambiguous answers which carry real significance, and it is very difficult from the questions “who are the developers or Git” or “who are the developers of Linux”.
One possible consideration is that software, being formal artifacts, doesn’t actually change with time. Rather, our society is what is changing, and software developers are creating new versions of software over time in order to keep up.
That’s a very interesting insight, really. But I fear it might not make any difference in practice.
The author goes from one misguided of a spectrum as just a binary - maintenance vs development - to another one - product vs project.
The same way that software can be anywhere along a spectrum of new development and maintenance modes, it’s development can also be in a spectrum of what he describes as product and project mode.
I’m aware of a distinction between product and project managers, but what do you mean by those terms as development modes?
The same thing the author meant?
Here is a converse view that I pretty much agree with… https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory.
Maybe I should expand on why.
I see in real life a complete and utter disconnect between “We need this feature” and “We made X amount from this feature” and “We spent Y developing this feature”.
When I look at some software systems and try estimate how many real live customers are using certain features… I bet most Phd thesis’s are more widely read, but there is a largish cost in test and maintaining them.
It is often not possible to calculate what that X mount is. Software is bought and used by humans and they are way to fuzzy for that.
In a previous job we had some horribly outdated part in the system that constantly broke and the functionality it provided used only by a few customers that probably only forgot to turn them off. It brought no value. Everyone in the team agreed that it cost way too much time and energy to maintain for what it provided. So we tried to get rid of it.
But that didn’t work. While the features were not very useful in practice, they looked nice in the marketing and helped explaining “the story”. A few sales people claimed it helped selling the product. So the features stayed. Because running an A/B test on that would not have worked.
Sales will always claim they need everything to sell anything, one of the constants of the universe.
We have X&Y, our competitors have X&Y&Z so we must have Z. (Actually we have X&Y&W and they have X&Y&Z, but sales doesn’t really understand what W does anyway., so on the quiet they aren’t even selling that feature)
And in the race for more points on the brochureware, usability and reliability and simplicity is lost.
Products become more complex than mere mortal can understand, and it becomes a market for lemons.
Eventually the market degrades to one premium product almost no one can afford, and one cheap and shitty one that has all the brochure points, but almost non of them are usable or work.
The classic example of this arc was wristwatches.
Eventually, no matter what face and wristband they had, and they had hundreds of different ones, they all had the same shitty core that was fundamentally flawed (too easy to accidentally reset the time).
I wish the effort was poured into simplicity and reliability, and then innovating something new in an adjacent product space.
Products die. If you’re working on a product whose death is scheduled, 100% of the work you’re doing is maintenance. All of that work was done before death was scheduled, therefore all products have maintenance work.
Maintenance work clearly exists, as is intuitive.