How important is software maintenance?

I grease my software every week and change the oil every 10,000 crashes.

How on earth do you maintain software ?

Compress the hard disk ?

Software maintenance is often the continued tinkering with code that happens after the system has been delivered. It seems to be necessary in far too many systems to my mind. Mostly it is because someone has not got a handle on nailing down the specs tight enough.

My own software does not need maintenance. If the requirements change after delivery it is a new project.

You're pretty lucky, then. Every once in a while I get a true "black box" project which is developed once, deployed, marketed, and never revisited. This usually means the product went nowhere, or was a one-off problem-solver for a very specific use.

More often, however, I get projects which grow and develop - the market wants a new feature, or a V2 of some kind... and then I have to be able to understand and work productively on my own code, despite having perhaps long since erased and re-used those particular neurons. I have one project which has been ongoing for nearly 20 years, entirely because of new features and enhancements, usually with intervals of a couple of years between feature requests.

And some people (clearly neither you nor I ;)) say "maintenance" when they really mean "bug fixing". V1 goes out in the market, and encounters some condition that was not known or recognised (or thought through) at spec time. Response times usually matter ;).

Summary: software maintenance, for anything but the most trivial of applications, is vital. This really means clarity of code - which isn't that hard to do *so long as* you accept that clear code takes less time overall to develop *and maintain* than the (far too common) alternative.

Unmaintainable code results in "stiffware" - code that no-one can, or wants to, maintain. This usually results in the next stage of development starting over from first principles...

YMMV.

Steve

... snip ...

Sounds appropriate.

Apply UPX to all executables?

The type of systems I build are usually "one-off" control systems for specific, high end, applications (power stations and railways mostly). With such systems a lot of effort goes in during development to eradicate any bugs in the spec, the design and the code. Such systems have to also prove they will work to the customers satisfaction before they leave the factory. Then follows on-site commissioning to prove it works to the customers and regulatory bodies satisfaction.

I know you and others here have a different type of embedded system where product enhancements are a continuation after the initial products are delivered. I suppose the question though is "is it really maintenance?". That question is sure to open up quite a long discussion about the definition of what is and is not maintenance.

Not nailing down the specifications is poor practice and companies that are guilty of this really deserve to be in deep doo doo. I don't consider fixing bugs that arise out of such poor practice as maintenance but more as product rescue. Judging by the costs involved in such gargantuan efforts one wonders why anything but "software shall be written such that it requires zero maintenance" is not a standard phrase in all initial requirements documents.

You are marching into the re-useable code arena here Steve. Very laudable aiming to re-use as much code (from trusted library collections) as you can so long as it fits the goals of the current design. Of course more re-use of trusted components should lead to less need for bug fixing effort later.

I know my mileage varies from yours but only because we deal in different types of product. However, I also know we have the same quality aims.