Hacker News Reader

Comment by chinchilla2020 | Hacker News Reader

chinchilla2020

In practice, the maintenance side eats up far more man-hours than the R&D side.

Every software project has a shelf life except for a handful of very low-level ones that have survived the ages.

All projects need maintenance until they reach their deprecation date.

I like saying the following: the difference between writing software and maintaining it, is the difference between raising your hands in the air and keeping them raised indefinitely.

i like that - great way of thinking about it.

Maybe more like raising a box onto a shelf in an earthquake zone. Then keep it on the shelf despite ground moving underneath every so often.

All of software maintenance is R&D. Whatever isn't is done automatically by your computer and you don't even acknowledge it.

Would the handful of low level ones include the many thousands of video games that run on pre internet consoles? One can argue that those projects are "finished" and not in need of maintenance but it really depends on your point of view. I'm sure people can find ways to say those projects are not finished (an example being the efforts to reverse engineer super mario 64 and zelda OOT have now shifted to correcting bugs in the game and squeezing every ounce of performance from the N64 given we now have foresight into how the hardware runs best)

They are "cheating" slightly though, because they get to run on a "unchanging" environment, i.e. the hardware is fixed and they generally don't have to suddenly support the latest version of Windows or similar.

I hear ya, and it goes back to how we want to define everything. Technically the software itself does not need maintenance. The "why" is because of unchanging hardware. Maybe more software should be developed for unchanging hardware. The problem is that the real world does not map well onto this paradigm.

....maybe AI will solve this problem for us one day. :P

Except the real world maps just fine...

At any point we could all just just agree to make an unchanging ExtremeLTS target if we really wanted. Just like, freeze a modern Linux and only do nonbreaking changes to any of the parts.

Unfortunately nobody seems to have done that for real practical use. There's UXN, which is cool, but I wouldn't want to use anything that minimal, especially not with the focus on ASM instead of a high level language.

We could also just decide to make a compiler to make N64 dev easier and just keep making most of our stuff for that, retro console games will probably always be playable for as long as civilization continues, but that would not exactly be practical.

But windows kinda already does the whole unchanging target thing, or did. Their backwards compatibility is so much better than Linux, where nothing works in 2 years because of all the dynamic linking.

I wrote a custom RSS reader nearly 20 years ago still runs fine.

Standard protocols rock. Sadly many RSS producers have degraded the content in their feeds which requires workarounds to get full articles or sign in or support new elements.

All software rots but some software rots much slower than others.

The thing about R & D is that most of the time what's needed is overcoming difficult but important milestones if not accomplishing actual major breakthroughs.

Failure on the preliminary R & D can be a complete show-stopper before you even get started.

OTOH with such limited, poor & incorrect documentation pertaining to the hardware & software, especially in combination with each other, a strong background in the Experimentation & Discovery aspect of R & D is often the only way to achieve your objective when the intended initial logical approach fails to perform as it is supposed to do. This need can penetrate beyond maintenance all the way to end-of-life.

One reason maintenance can chew up so many man-hours.

Reply on news.ycombinator.com