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

31–40 of 116 posts

Re: Let’s Get Excited About Maintenance

#31

Post by swsieber »

wildmusings wrote: post #14
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 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…

Heck, I work on a web product, and I regularly work on code a decade+ old. None of the developers who wrote that code are around anymore, except for the heads honcho. It always surprises me when I go to use git blame to see code that old (going to git blame to get a better understanding of the purpose), and at that point it's was actually an svn commit I'm looking at.

Fun times. It shouldn't surprise me that since the code from that time uses Hungarian notation.

Re: Let’s Get Excited About Maintenance

#32

Post by mrep »

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

Re: Let’s Get Excited About Maintenance

#34

Post by lj3 »

wildmusings wrote: post #14
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 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?

Re: Let’s Get Excited About Maintenance

#35

Post by nathanvanfleet »

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?

Re: Let’s Get Excited About Maintenance

#36

Post by dmoy »

mrep wrote: post #32
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 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.

Yea ditto, I just fixed a bug in some other team's 5 year old code cus it was breaking on some of my team's stuff. Beyond some ungainly test code involving counting byte offsets, it wasn't that bad. The fix involved dropping in some other 5 year code via a library and voila it worked.

I get some of what gp is saying, some older stuff gets abandoned and not improved much, while other stuff gets modified so much that it's sorta like that "at what point does a ship become a new ship though gradual replacement of all timber?" question.

Re: Let’s Get Excited About Maintenance

#37

Post by xamuel »

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.

Re: Let’s Get Excited About Maintenance

#38

Post by sengork »

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…

Operational innovation is maybe the term you are looking for.

Re: Let’s Get Excited About Maintenance

#39

Post by akkartik »

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…

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 interfaces. With hindsight, it seems clear they were prematurely frozen.

Rather than dismiss these observations as isolated cases of people not practicing good behaviors, I tend to see them as evidence that we should be creating libraries far more conservatively, freezing interfaces far more late in the life cycle, perhaps even decades late.

If I'm right, we are also overusing industrial notions of assembly lines and division of labor. Libraries with non-trivial functionality take a long time to get right, and in the meantime they are produced more like guilds of craftsmen than factories. (Even if the products themselves permit factory-like operation at scale.) In that initial bake-in period we are ill-served by conventional metaphors of software components, building blocks, etc. We should be dealing more in vertically-integrated self-contained systems rather than plug-and-play libraries. More OpenBSD, less `gem install`.

I've been thinking about this for at least five years, ever since http://akkartik.name/post/libraries. More: http://akkartik.name/prose

Re: Let’s Get Excited About Maintenance

#40

Post by wildmusings »

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?

A few things come to mind:

- Windows is (mostly) a platform, not an end application. So you need...

- Backwards compatibility. It is a pretty hard requirement, as one of the major selling point of Windows is that your existing stuff will keep working. Programs targeting 16-bit Windows from the early 90s still work on Windows 10 (though they recently removed the 16-bit subsystem from 64-bit Windows). I believe it's the same with Office document formats. You already have the code that handles all of the old APIs and functionality, so...

- If it ain't broke don't fix it. The old code has been thoroughly battle tested. Obscure edge cases have been addressed. Bugs have been fixed over the course of many releases. There is no chance that your rewrite will avoid regressions, and you'll almost certainly introduce new bugs too. It's better to make necessary changes to the old code than to try to start from scratch. And...

- It's a lot cheaper too.

Joel Spolsky has a great blog post about rewrites: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Post reply on HN