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

101–110 of 116 posts

Re: Let’s Get Excited About Maintenance

#101

Post by kutkloon7 »

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

Re: Let’s Get Excited About Maintenance

#102

Post by akkartik »

lmm wrote: post #74
akkartik wrote: post #39

Earlier quoted context omitted.

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…

Libraries do take a while to get right, but I think we can only get them right by making them as libraries. All good libraries I've seen started out as part of a vertically-integrated piece of software, but if there's currently an immature library for x, using that immature library generally puts us further along the path to getting a mature library for x than writing your own vertically-integrated implementation of…

Getting more users for x certainly helps mature it. However, making it a library also tends to freeze it. So ideally we'd have ways to encourage people to use something without guaranteeing its interface. I think this is a social problem; we need more libraries that have signs on them saying, "alpha software, compatibility not guaranteed," and we need greater awareness among developers that this is a good thing, that being willing to switch interfaces every once in a while results in a better eco-system in the long term.

Re: Let’s Get Excited About Maintenance

#103

Post by artursapek »

emiliobumachar wrote: post #100
artursapek wrote: post #96

Earlier quoted context omitted.

The SMBC comic mocks the people for not being self-aware enough to realize that they are causing their own problem by being apathetic. > "I'm not good at this because I don't try, so I won't try" > "Girls don't like me because I have bad hygiene, so why should I bother with hygiene?" etc. This would only apply to what I wrote if my code was disappearing because it's not formatted to pass a linter. You and I both know…

> code quality is not the same thing as code style. I did misparaphrase you. My apologies for that. Fixed. But as for the other argument, I think the comic's examples and your case represent feedback loops in which two factors are both cause and consequence of each other. I believe you that you started not caring about code style after you noticed your code tends not to last. Similarly, life was short already before…

No, I don't think it matters. Obviously there's a line you have to draw, like tabs vs spaces, but I don't care if you place your commas differently from me. Code being so ugly it's hard to read is a problem, but arbitrary fashion is not worth the time.

Re: Let’s Get Excited About Maintenance

#104

Post by adrianN »

saltyworker wrote: post #85
nightski wrote: post #45

Earlier quoted context omitted.

The fact that you need a sexy word is indicative of the problem.

The fact that you need a sexy word is indicative of _human nature_

Words don't become sexy by themselves, they become sexy because they're labels for sexy things.

Re: Let’s Get Excited About Maintenance

#105

Post by Mathnerd314 »

kerkeslager wrote: post #86
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…

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…

Global state is actually a good model, see https://awelonblue.wordpress.com/2012/10/21/local-state-is-p....

The issue is more one of fragmentation; figuring out which file(s) / method(s) are responsible for some item of state can get to be impossible without a powerful debugger, and constantly changing frameworks / libraries don't help.

Re: Let’s Get Excited About Maintenance

#106

Post by lmm »

akkartik wrote: post #102
lmm wrote: post #74

Earlier quoted context omitted.

Libraries do take a while to get right, but I think we can only get them right by making them as libraries. All good libraries I've seen started out as part of a vertically-integrated piece of software, but if there's currently an immature library for x, using that immature library generally puts us further along the path to getting a mature library for x than writing your own vertically-integrated implementation of…

Getting more users for x certainly helps mature it. However, making it a library also tends to freeze it. So ideally we'd have ways to encourage people to use something without guaranteeing its interface. I think this is a social problem; we need more libraries that have signs on them saying, "alpha software, compatibility not guaranteed," and we need greater awareness among developers that this is a good thing, that…

Agreed. But I think the idea of listing and cutting down your dependencies (which is what I understood your post to be suggesting) is contrary to that; rather depending on a huge number of tiny libraries makes it easier for libraries to evolve more flexibly.

Re: Let’s Get Excited About Maintenance

#107

Post by michaelt »

HillaryBriss wrote: post #90

> 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?
According to Wikipedia [1], "Erosion at the base of the weir—which was expected—progressed much faster than anticipated. The headward erosion of the emergency spillway threatened to undermine and collapse the concrete weir [...] Fearing a collapse, the Butte County Sheriff's Office issued an evacuation order of the Oroville area. [...] Engineers worried that [...] damage to the main spillway could grow uphill to the point that it endangered the main spillway gates, leaving no safe way to release water. [...] By February 13, 188,000 people in the vicinity were reported evacuated. About 23,000 National Guardsmen were ordered to be ready for 'immediate deployment if the dam spillway should fail' to help with evacuation and relief efforts."

That sounds a lot like a near-collapse to me.

Of course, you could argue the authorities acted with a surfeit of caution - perhaps there was only ever a one-in-a-thousand chance of the dam collapsing, and the threshold for 'nearly collapsed' should be a one-in-five chance of collapsing. However, I think most reasonable people would say that a one-in-a-thousand chance of killing 188,000 people living below the dam is several orders of magnitude too high.

[1] https://en.wikipedia.org/w/index.php?title=Oroville_Dam_cris...

Re: Let’s Get Excited About Maintenance

#108

Post by reitanqild »

watwut wrote: post #53
lj3 wrote: post #34

Earlier quoted context omitted.

> What you're saying is probably more true in the web dev world. Any world in which OOP is the primary paradigm. Then again, I've seen truly horrid procedural code as well. Do you have any specific ideas on why the code you're working with seems to be the exception to the rule? Or is it pretty much all in that blog you linked?

I have seen or worked multiple still maintained projects way older then 5 years - with parts of old code still there. Most of them in java or .net.

5 years old Java code is really no problem as long as it uses maven as build tool (and don’t use long deprecated code generation tools).

This is the main difference l see between maintaining old Java code and e.g old Delphi code:

In maven/java I can run a couple of commands to build it, open it in any of my three favourite IDEs (Netbeans, IntelliJ and Eclipse in that order) and it just works.

In other languages there is often some dependency hunt involved before you can even start. Bonus for dependencies that must be installed using .exe installers, in a specific order (hint: if you don't get it right - good luck with cleaning the registry before trying another installation order.)

I might have been very unlucky in my encounters with legacy code in other languages but so far every encounter makes me love the Java ecosystem more.

(Although I'll happily admit that parts of it might be related to the fact that Java developers seems to avoid using non oss code to a much larger degree than anyone else - maybe except from php and js devs?)

Re: Let’s Get Excited About Maintenance

#109

Post by potbelly83 »

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.

Re: Let’s Get Excited About Maintenance

#110

Post by marcosdumay »

csours wrote: post #52
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…

Continuous Improvement is the lean manufacturing term for it.

Continuous improvement is more like the kind of maintenance you do to software than the one you do to infrastructure.

I don't think the name would matter in any way. It's more a problem of what voters value, or what politicians think that voters value.

Post reply on HN