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

51–60 of 116 posts

Re: Let’s Get Excited About Maintenance

#51

Post by sebcat »

alextheparrot wrote: post #23
artursapek wrote: post #16

Earlier quoted context omitted.

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.

Manual linting is silly, but having a linter installed really saves a lot of pain. Git diffs should not include unrelated linting changes.

Having a company wide git hook for clang-format-diff [1] really solves a lot of problems. No unrelated linting changes (unless people don't know how to use their editor, but that gets caught in code review and people learn) and consistency is kept with very little man-hours spent. Proper tooling applied pragmatically is nice.

[1] http://clang.llvm.org/docs/ClangFormat.html#script-for-patch...

Re: Let’s Get Excited About Maintenance

#52

Post by csours »

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.

Re: Let’s Get Excited About Maintenance

#53

Post by watwut »

lj3 wrote: post #34
wildmusings wrote: post #14

Earlier quoted context omitted.

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

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

Re: Let’s Get Excited About Maintenance

#54

Post by drawkbox »

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…

"Quality of life" improvements would be better. People can motivate themselves if it improves their quality of life. We do daily maintenance, life itself is mostly maintenance, but you can make it worthwhile, and sometimes fun, by focusing that on improving your quality of life and time.

Re: Let’s Get Excited About Maintenance

#55

Post by Waterluvian »

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…

Let's all go remaster our local park!

Re: Let’s Get Excited About Maintenance

#56

Post by eight_ender »

eloary wrote: post #13
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…

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

This is made worse by the few brave developers that will dive in getting all the anger if they make a mistake, at a massive scale if the library is popular.

Re: Let’s Get Excited About Maintenance

#57

Post by sAbakumoff »

BatFastard wrote: post #9
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 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.

Apparently developers compare their sizes too.

Re: Let’s Get Excited About Maintenance

#58

Post by vacri »

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?

Re: Let’s Get Excited About Maintenance

#59

Post by pontifk8r »

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…

Sustainability Engineering?

Re: Let’s Get Excited About Maintenance

#60

Post by vacri »

acomjean wrote: post #42

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

That's the problem of being a maintainer. You point at something and say "that's still working", and no-one knows if it's because nothing has happened anyway, or because you ended up fixing some fatal error in it.

New features are also pretty easy to measure in terms of throw money in, get features out. Maintenance... how hard do you go? How much is too much? Do you just need a light check-in? Do you need full reviews? Or is that just wasting money for no reason?

Post reply on HN