I mean, I think the best way to start with this is to use a word other than "maintenance." That's not really the most sexy word if you really want people to get behind it. Furthermore it just suggests that the work is keeping something as good as it was from the beginning. Filling in holes, giving it a coat of paint every now and then.

What it really should be called is "refinement." The innovation ends up being incredibly crude but it gets the job done. How can we build on that, make it better and less coarse than it was? How can we make it more efficient?

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

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

The problem seems to be that we've invested far too much federal money into projects that have to be maintained by local sources of funding. Big federal grants for development that will not produce enough tax revenue to offset the externalities and infrastructure costs that are required to maintain that development are just albatrosses around states and cities' necks.

https://www.strongtowns.org/journal/2017/1/10/poor-neighborh...

In Philadelphia, I passed under the Columbia Bridge by foot, and nearly fell over when I looked up. An entire section of the bridge has spalled and a huge gap of reinforcing steel rods is rusted and exposed. This bridge will collapse. I found no evidence that there is any plan to reinforce or replace it. Luckily it "only" carries CSX freight. Anyone passing under it should be extremely wary.

https://goo.gl/maps/uFkLJoKU1DB2 https://goo.gl/maps/767CYu5Mwd62 (it actually looks worse than this up close)

I'd be interested to find out what the track record is of maintenance of infrastructure by private vs public entities.

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.

Sometimes you need to stop maintaining things. Towns rise and fall because the economy changes. If there's no economic activity bringing money into a town, it should eventually disappear. You need the political courage to stop wasting money on propping it up. Some bridges, pipes, roads, and trains shouldn't be repaired or replaced. They need to be closed if dangerous, and allowed to disappear into history. If holdouts want to keep living in their dead town, good for them, but don't make the rest of us pay for it.

Stewart Brand, "The romance of maintenance is there is no romance of maintenance". This was basically his point in "How Buildings Learn" (and really the Long Now too)

While maintenance is certainly undervalued, I don't think that means innovation is overrated.

We stepped out of the plane in New York and soon my Iranian wife called her mother. "Mom, the roads are about as bad as in Tehran!". Recently, we were in Tehran again: they had invested heavily in the maintenance of their infrastructure, making the roads better than in many American cities.

Its hard too. my current job with a large existing code base (perl/python/shell scripts and java), and keeping it up to date is a large portion of my time.

The thing is I get very little credit for fixing something that is broken, but creating something new generates accolades and the illusion of productivity...

I agree with others on the thread that "maintenance or innovation" is a false dichotomy. In particular, I think we need innovative maintenance. For e.g., this article about new ways to fix potholes: https://www.economist.com/news/science-and-technology/217003...

Freakonomics did a great story on maintenance last October. http://freakonomics.com/podcast/in-praise-of-maintenance/

>The American Society of Civil Engineers considers 17 percent of American dams to be “high hazard potential,” including the one outside Oroville, Calif., that nearly collapsed in February.

Is this exaggeration? Would any reasonable person say that the Oroville dam nearly collapsed?

  Would any reasonable person say that the Oroville
  dam nearly collapsed?

I think a large part of this is how we hire people. It looks much more sexy on your resume (and prepares you better for interview type questions) if you have experience building from scratch a fancy machine learning pipeline, than maintaining a 100K+ legacy (say > 15 years old) C++ code base.

Not only this, but I've lost count of the number of young guys I see come into my company (especially the machine learning guys), spend a year exploring some new technology, then jump ship to a different company when it comes time to integrate it with the existing legacy code base.

I'm a big fan of this topic. Something we seem to forget is that sometimes new is not necessarily better.

HN had another article about this recently:

https://news.ycombinator.com/item?id=14293775

"Americans have an impoverished and immature conception of technology, one that fetishizes innovation as a kind of art and demeans upkeep as mere drudgery."

Pretty much hits the nail on the head, although I want to note this does not exclusively apply to Americans (but maybe a bit more than Europeans; technology is often a lot cheaper in the US: it is not uncommon that the amount of dollars paid for an item is lower than the amount of euros, even though euros are worth quite a bit more).

It is especially bad for phones. Many people I who are (almost annoyingly) aware of the environment buy a new phone every year.

I am guilty myself too. My current phone is about two years old. It has a full HD screen, a luxury that I don't even need on my laptop (about half of the time, I work on a 1440x900 thinkpad). And, to be honest, it is getting quite sluggish. When I open dropbox or tinder, I experience a delay up to 10 seconds, which is quite ridiculous (it especially bothers me that software seems to get slower, more bloated, and more abstract and complicated). People's first reaction to hearing this is "Just buy a new phone, man". I shouldn't be, but I am indeed considering this.

How many times are they going to write this article?

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.

This is a product short tenures: software developers switch jobs every 18 months on average, so they don't get to see the long-term effects of their decisions. This leads to decisions with big payoffs in the short term that come back to bite you in the long term. Some examples:

1. Pervasive, maximal frameworks that favor terse magic over clear explicitness. At first this allows you to spin up a website in a few lines of code, but years down the line you're spending all your time reverse-engineering a workaround for a bug in Ember 0.2 so you can implement the same functionality in Ember 17.3 when the controller that it referred to is no longer in the codebase and the naming convention for tying together models and views has changed twice.

2. 0.x versioned libraries which solve the problem you have today, but cause 100 problems tomorrow when the maintainer deletes the repo.

3. Global state, which lets you bypass having to pass data through to components until later when you want to have more than one component per page.

You haven't worked in a large company. :-) Much of the code behind your phone, the train system, chain restaurant ordering and any paper bill you get is likely 10+ years old. These companies undertake 5-year programs to replace ancient systems, and the 5-year programs frequently fail, and run late when they don't.

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

What world are you living in? I work for one of the big 5 and 75% of the software stack features I use have been in continuously developed for over 5 years.

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.

Totally with you. I've been thinking of it as rewrite-friendliness, and have some ideas for encouraging it: http://akkartik.name/about

Even if people don't believe that all code over five years old is doomed, writing code to be easy to rewrite still seems like a useful idea. You're preserving optionality, you're making it easier to try out multiple designs, and you'll have an easier time recruiting collaborators because they'll have more fun projects to try, and so they'll be more likely to progress 'down the funnel' from using a project to hacking on it to contributing it all the way to taking over its running.

You would be surprised how long lived some code is. I used to work on codebase that was started during 70s and currently working on codebase written around 1995 - 1998 and maintained until today.

There is wast amount of code used daily that is decades old, especially if those systems are not user facing.

I don't share the same sentiment. I routinely see active code being supported that 10 to 20 years old. Granted, it's no joy to work on, but it does get maintained.

I'm curious what kind of environment you work in where where most stuff stops being used after 18 months...

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

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

>not totally sure how to achieve it [replaceability]

One of the most crucial keys is: make your code greppable. For example, don't treat OOP classes as a license to use generic method names ("add", "set", "close", etc.), or it'll be difficult to weed those classes out.

Replaceability is just system-level maintainability.

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.

"replace-ability vs maintainability" They are the same thing...

Congratulations, you are one short step away from realizing, that replace-ability for their own software is the least thing any company wants.

There are many ways into the walled gardens, but none out.