Let’s Get Excited About Maintenance
nytimes.com
Let’s Get Excited About Maintenance
1–10 of 116 posts
Re: Let’s Get Excited About Maintenance
#2I'm a big fan of this topic. Something we seem to forget is that sometimes new is not necessarily better.
Re: Let’s Get Excited About Maintenance
#3(tangentially related to this article)
I have recently come to realize that, at least in my world, source code older than five years is basically doomed. Developers simply refuse to work on it.
The code that makes it to five years is extraordinary as most of it "dies" before reaching the eighteen month mark.
As a result I have recently been shifting my view to support replace-ability vs maintainability whenever possible. I'm not totally sure how to achieve it, though. Most current trends seem to be towards increasing baggage. (docker)
Data lives on and on and on, however. Data is king. :)
Re: Let’s Get Excited About Maintenance
#4While maintenance is certainly undervalued, I don't think that means innovation is overrated.
Re: Let’s Get Excited About Maintenance
#5I always think this is the big strength and weakness of the US at the same time. This country is more willing than other countries to abandon old things and move on to the next thing. But right now it seems to be falling into the trap of a lot of pseudo innovation while the foundation is crumbling. Not sure what the best way is to move forward.
Re: Let’s Get Excited About Maintenance
#6While maintenance is certainly undervalued, I don't think that means innovation is overrated.
I think there is a lot of fake innovation happening these days. I bet if the programmers of the 70s had had the same amount of computing resources available as we have now they would have built great systems even with the tools available then. Other than the cloud and more computing and network power I don't think software development has really moved forward much.
Re: Let’s Get Excited About Maintenance
#7This article posits that you can either maintain, or innovate. This is not at all true. We can, and should, innovate while maintaining to improve our maintenance.
We can use automation to gather data we've never had before. We can use this data to help prioritize maintenance tasks, and get them done faster with less interruption to service.
Re: Let’s Get Excited About Maintenance
#8While maintenance is certainly undervalued, I don't think that means innovation is overrated.
I think there is a lot of fake innovation happening these days. I bet if the programmers of the 70s had had the same amount of computing resources available as we have now they would have built great systems even with the tools available then. Other than the cloud and more computing and network power I don't think software development has really moved forward much.
> Other than the cloud and more computing and network power I don't think software development has really moved forward much.
So a person from the 70s who was instantly transported to today would feel like the only difference is that instead of having our own servers we ship things to Heroku? Please...
Re: Let’s Get Excited About Maintenance
#9(tangentially related to this article) I have recently come to realize that, at least in my world, source code older than five years is basically doomed. Developers simply refuse to work on it. The code that makes it to five years is extraordinary as most of it "dies" before reaching the eighteen month mark. As a result I have recently been shifting my view to support replace-ability vs maintainability whenever possi…
You have obviously not been a developer for very long. I commonly use code that is 20 years old. Of course that code is well maintained C and C++ code.
This is one reason the not acquiring or correcting technical debt is so important for the long term health of a company.
Now I agree that data is king, but if you have to rewrite you code base every 5 years you are doomed.
Re: Let’s Get Excited About Maintenance
#10(tangentially related to this article) I have recently come to realize that, at least in my world, source code older than five years is basically doomed. Developers simply refuse to work on it. The code that makes it to five years is extraordinary as most of it "dies" before reaching the eighteen month mark. As a result I have recently been shifting my view to support replace-ability vs maintainability whenever possi…
>Most current trends seem to be towards increasing baggage. (docker)
I'd disagree, docker for example makes it easier to create infrastructure as code which in turn makes it easier to replace pieces of that infrastructure. Same with micro-services which allow you to eventually replace isolated pieces of your infrastructure. The more modular and isolated pieces of code and infrastructure are the easier they are to replace piecemeal.