On 23 November 2016 at 12:33, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote: > When I get flak about the churn of staying current with maintenance, I climb > my soapbox. Look, I say, I've calculated that on balance it's cheaper to > drive your car as long as it runs rather than take in for periodic > maintenance, which is both time consuming and out-of-pocket costly. Most > likely it will fail somewhere down the road ;-) but getting it fixed then > will be cheaper and quicker overall. > > Well, I say, if you wouldn't think of managing your car that way, why would > you think it makes sense for a computer system?
The analogy is cute, but I think it fails The problem is that in some circumstances that's a perfectly reasonable way to manage a car. Depending on the age, how much you depend on it, whether you ever drive a significant distance from home, etc. etc. there may be nothing wrong with deferring or not doing some maintenance. I live in a city, mostly walk or use transit, and I have very little need for reliability in a car. So generally on my cars I do oil changes and have safety systems (e.g. brakes) inspected and serviced *as necessary*, but otherwise I do "drive it as long as it runs". This works for me and the way I use a car; obviously not so well for someone who lives in a rural area, drives a long commute to work, and/or has no easy backup options for transport. There is even a credible argument that many kinds of so-called preventative maintenance cause more harm than good. For example, taking apart and repacking a wheel bearing on a routine periodic basis may well cause earlier failure than leaving it alone. It depends. If you want the best possible reliability from a car (which is not, of course, the only reasonable goal), probably the semiconductor "bathtub" curve roughly applies: you should buy one that is past its "burn-in" period, but not too much, and then keep it only until some time before it reaches its predicted wear-out failure rate increase. I'm guessing these numbers would be perhaps 3 months and 24 months, or equivalent distance travelled, respectively. https://en.wikipedia.org/wiki/Bathtub_curve But little if any of this applies to software. [There is a lot of stuff on Google about maintenance and cost/benefit analysis as applied to various kinds of hardware, typically industrial machinery and of course aircraft. Unfortunately a great deal of it is written by people whose business it is to sell the benefits of PM, so it takes very careful reading, even of academic articles.] There's also a very good argument that calling software fixes and their application "maintenance" is a logical or category error. Software does not "wear out" the way hardware does, and it also cannot be replaced to solve a problem (at least in the sense of installing an identical new copy as you can with a car or an aircraft engine), but rather *must* be fixed. Please note that I am *not at all* saying that routine fixes should not be applied to software, or that the management attitudes you complain of are good. It's the analogy I'm quibbling with, not good software practice. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
