Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let’s Get Excited About Maintenance

nytimes.com

Post reply on HN
Print view View original

61–70 of 116 posts

Re: Let’s Get Excited About Maintenance

#61

Post by wildmusings »

vacri wrote: post #58
wildmusings wrote: post #44

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

So you're saying that NYC's infrastructure (the city in the article's opening paragraph) is crumbling because there's no economic activity bringing money into the city?

No, I'm speaking in general.

Re: Let’s Get Excited About Maintenance

#62

Post by peterwwillis »

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.

Re: Let’s Get Excited About Maintenance

#63

Post by dejv »

liveoneggs wrote: post #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 possi…

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.

Re: Let’s Get Excited About Maintenance

#64

Post by omegaworks »

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

Re: Let’s Get Excited About Maintenance

#65

Post by maccard »

eight_ender wrote: post #56
eloary wrote: post #13

Earlier quoted context omitted.

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

I don't argue your point here, but I'm seeing more and more developers that cut their teeth in the age of libraries that are terrified to touch library code. There's an assumption out there for some that library code is flawless, and there's an imposter syndrome type aversion to touching it, with the developer fearing the code was made in a certain way for a certain reason and that they're not skilled enough to work…

I work on a closed source project using closed source libraries with some restricted source access. In general, if I find a bug in that library, it's less hassle for me to report it to them, and move on, than report it, fix it, and deal with the upgrade path later. It's unfortunate, but if I fixed every bug I found in the third party libraries, I'd never get any of my own work done..

Re: Let’s Get Excited About Maintenance

#66

Post by majewsky »

xamuel wrote: post #37
liveoneggs wrote: post #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 possi…

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

Depends. If you have a statically typed language, you can usually just delete the class and fix all the compile errors. With a dynamically typed language, your point stands and I very much agree.

Re: Let’s Get Excited About Maintenance

#67

Post by billysielu »

akkartik wrote: post #28
liveoneggs wrote: post #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 possi…

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

I love your website. My experience (web app for heavily regulated industry):

- Customers don't want major versions to be continuously deployed. Each deployment involves validation and training. They want the software to be left alone, perhaps with the occasional bug fix.

- The business needs new features to stay competitive.

- So you're left actually needing to host multiple versions. All the major versions the customers are on, and want to stay on, and one latest-and-greatest version for winning new business.

- Never force a new feature on a user. It becomes obvious that you're building things that most of your customers don't want. This means don't create a major version and automatically deploy it.

- Moving data between systems is hard. Plan to never move data between systems, or major versions of the same system. Users prefer to see their data where they left it, looking exactly how they left it. A major version should be empty. If you constrain a new version of your software based on old data, sooner or later you're stuck, either because of schema or because of volume.

- So if you have a big new feature, you save it for the next rewrite.

- Once you've decided that at some point in the future you're going to do a rewrite, things fall into place nicely...

- You avoid the situation where your dev team is mostly useless apart from the few guys who originally wrote the system.

- You avoid the endless accumulation of data.

- You avoid being commanded by the product team.

- You avoid being hated by your users, and your clients.

- You avoid spending huge amounts of time and money on things you didn't really need to do.

- You avoid the end of your business, which is inevitable given ~10 years of 'current best practice'.

- The part that I don't know yet is... developers have been avoiding rewrites for so long, we haven't really got good at it. We need to do it, do it often, learn how to do it well, and share that experience.

Re: Let’s Get Excited About Maintenance

#68

Post by noway421 »

throwawaycanada wrote: post #46
nathanvanfleet wrote: post #35

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

Call it long term support logistics and operations.

Or maybe just "Support"

Re: Let’s Get Excited About Maintenance

#69

Post by icebraining »

billysielu wrote: post #67
akkartik wrote: post #28

Earlier quoted context omitted.

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

I love your website. My experience (web app for heavily regulated industry): - Customers don't want major versions to be continuously deployed. Each deployment involves validation and training. They want the software to be left alone, perhaps with the occasional bug fix. - The business needs new features to stay competitive. - So you're left actually needing to host multiple versions. All the major versions the custo…

1-4 jibe with my experience.. that's why we built a SaaS cloud that allowed each customer (company, not individual users) to run a specific version of the platform, rather than the full multi-tenant model where everyone is on the same track. The latter may work for peripheral applications, but for core business apps it's a non-starter.

Unfortunately, it often felt that we were having to write everything from scratch; you can barely find anyone talking about this model, or any tools designed to handle it. Everyone seems to be either fully multi-tenant or manually launching individual servers (which is not feasible for low price SaaS).

Re: Let’s Get Excited About Maintenance

#70

Post by billysielu »

akkartik wrote: post #39
eloary wrote: post #13

Earlier quoted context omitted.

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

This tends to be mainstream opinion today: figure out the timeless essence at different scales, decompose it into abstractions, freeze their interfaces so that people can start relying on them, and so on. But it doesn't seem to have helped for forty years of trying to do it. The world changes too quickly, we aren't quite as good at designing libraries as we think, the world is filled with historical accidents in inte…

I agree. It's especially pungent in JavaScript, in which the average 'JavaScript developer' is playing some perverse game of library pokemon.
Post reply on HN