Jed Rothwell wrote: > Stephen A. Lawrence wrote: > >> > The number of bugs in a software package decreases at first >> > and then increases, inexorably, to the point where the software becomes >> > unusable. >> >> Can you name an example where this has happened? > > It has happened to every software package I ever wrote which remained in > use.
At the risk of sounding offensive, I would like to observe that the fundamental design of any package limits the degree to which it can be modified before the modifications become unmaintainable. This could be called the "design life", and it doesn't have to do with the number of fixes applied; rather, it has to do with how much you want to *change* it from its original purpose, and it has to do with the flexibility of the original design. Adequate software design makes a huge difference in the design life of a product. > > Naturally if you perform no maintenance and fix no bugs, and you leave > the program exactly as it is for 5 or 10 years, it will work as well as > it ever did. The driver and software for my Hewlett-Packard scanner > hasn't been changed or updated in years, but it still functions.... Emacs, Linux, Mac OS, Solaris, OpenOffice, MS Word -- would you claim that any of these have simply been left to sit on a shelf, and that's why they haven't become so buggy they can't be used? > Brooks, by the way, refers to the book Frederick P. Brooks, "The > Mythical Man Month," (Addison-Wesley, 1975). Yeah, we've learned some things about software design since 1975. In 1975, how old was an "old" software package? A few years? Ten years, at the outside? Things have changed. Nowadays there are products on the shelf based on code which dates back 20 or 30 years. I have named a bunch of them, all of which have undergone extensive maintenance over the years, and none of which have shown a user-visible "bug explosion" effect as a result of "too much maintenance". 1975 ... that was before strong typing, OO design, 'programming in the large', or a host of other methodologies which enable a good designer to produce a more flexible, maintainable product. 1975 was nearly two decades before ANSI C. Between "="/"==" confusion, lack of unclosed-comment detection, lack of strong typing, and lack of subroutine argument declarations, anything written in pre-ANSI C was necessarily so fragile that it would not be surprising if every new fix introduced new (really horrible) bugs. All external names were limited to 6 characters in length in those days, too, IIRC, which meant "self documenting code" was an unrealizable dream, and would remain so for many, many years. "Lint" was, at best, an awkward crutch which allowed one to limp forward a little faster with the tools available at the time. But as I said, things have changed.
