Live data from Hacker News

Let’s Get Excited About Maintenance

nytimes.com

11–20 of 116 posts

Re: Let’s Get Excited About Maintenance

#11
post #8
post #6

Earlier quoted context omitted.

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

[deleted]

Re: Let’s Get Excited About Maintenance

#12

(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…

Replaceability is just system-level maintainability.

Re: Let’s Get Excited About Maintenance

#13

(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…

I believe the right way to go is to focus on library code. If the long lived code is to prove exceptional it has to do so by being grabbed and bolted on to the new thing over and over, and that tends to favor an approach of libraries that assume very little, don't have many dependencies themselves, and opt for simple/robust API over being efficient. The API user can always recode the API for efficiency in their use case while as a library vendor your ability to guess at hotspots is limited at best, and as a consumer one is always looking for a library that can be used easily and disposed of quickly. In effect, "design by placeholder".

Re: Let’s Get Excited About Maintenance

#14

(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…

I used to work on Windows and would pretty often edit source files that were written over 20 years ago, sometimes by the guy four levels above me in the chain of command, back when he was an individual contributor. I actually preferred the C and older C++ components, with no exceptions and manual memory and error handling, to the "modern" C++ components.

I recommend Raymond Chen's blog, The Old New Thing, for some cool stories about how and why ancient Windows/Office components were written a certain way, and what the effects down the line have been. Among other things. https://blogs.msdn.microsoft.com/oldnewthing/

What you're saying is probably more true in the web dev world.

Re: Let’s Get Excited About Maintenance

#15

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

I've been writing code for over 20 years now, longer in the industry than in academia now. The trend toward using the latest, shiny new thing seems to me to have accelerated, too. I would like to go back to a job where I work on code that includes decades old C and C++. Unfortunately those jobs tend to pay significantly less than others I can get.

Re: Let’s Get Excited About Maintenance

#16

(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…

This is exactly why I roll my eyes when devs passionately argue in favor of "consistent code style" and spend hours of their lives manually linting their code. What's the point? It will be gone next year.

Re: Let’s Get Excited About Maintenance

#17
post #8
post #6

Earlier quoted context omitted.

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

I think they could get up to speed pretty quickly, yes. The ideas were all there.

Re: Let’s Get Excited About Maintenance

#18

(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 rep…

Disagree. Simplicity in unnecessary abstractions is still convuluted.

Although, I concede Docker is the bees knees for local dev.

Re: Let’s Get Excited About Maintenance

#20
post #5

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

Gerrymandering severely curtails political incentives for infrastructure investment. Not saying it's the only issue, but it's a clear case of undermining the best outcomes from representational democracy.
Post reply on HN