Software rot

Abstract: Software is no longer creeping into every aspect of our lives - it's already there. In fact, failing to recognize just how much everything we do depends on software functioning correctly makes modern society vulnerable to software errors.

Abstract: here is little doubt thefield of software engineer-ing, like all other engi-neering fields, has helpedmake life what it is today. Withsoftware controlling more equip-ment, software engineering isbecoming an integral part of ourlives. However, unlike many otherengineering fields, the productsproduced through software engi-neering are largely intangible.Also, unlike the products of otherengineering fields, software prod-ucts are unlikely to remain stableover a long period of time.This column is the first in aseries offering insight into thecentral themes of software stabil-ity. In this series we examine theunique characteristics of softwarethat distinguish it from otherengineering fields. We also studythe artifacts of analysis, design,development, and other factorsthat tend to produce stable orunstable software products. In hardware areas, failure ratesof products often start high, droplow, and then go high again.Early in a hardware product’s life-cycle, there are some problemswith the system. As these prob-lems are fixed, the failure ratedrops. However, as hardware getsold, physical deterioration causesit to fail. In other words, thehardware wears out and the fail-ure rate rises again.Software, on the other hand,is not subject to hardware’s samewear and tear. There are no envi-ronmental factors that cause soft-ware to break. Software is a set ofinstructions, or a recipe, for apiece of hardware to follow.There are no moving parts insoftware; nothing can physicallydeteriorate. Software should notwear out. Unfortunately, it does.Countless authors in the field ofsoftware engineering have identi-fied this problem. However, thesoftware engineering techniquesoutlined by many software-engi-neering authors have notachieved an adequate amount ofstability in software projects.This problem is more than justan inconvenience for softwareengineers and users. The reengi-neering required for these soft-ware products does not comewithout a price. It is common tohear of reengineering projectscosting hundreds of thousands, tomillions of dollars. This does nottake into account the time wastedby continual reengineering.Software defects and deteriora-tion are caused by changes insoftware. Many of these changescannot be avoided. They can,however, be minimized. Cur-rently, when a change is made toa software program, most of thetime the entire program isreengineered. It doesn’t matter ifthe change is due to new tech-nology or a change in clientele.This reengineering process isridiculous. If the core purpose ofthe software product has notchanged, why, then, must theentire project be reengineered toincorporate a change?The concepts of “enduringbusiness themes” (EBTs) and“business objects” (BOs) havebeen introduced as a proposedsolution to this problem. Theidea in this case is to identifyaspects of the environment inwhich the software will operatethat will not change and caterthe software to these areas. Themajority of the engineering doneon a software project should bedone to fit the project to thoseareas remaining stable. Thisyields a stable core design and,thus, a stable software product.

Abstract: A method of protecting a software program from unauthorized modification, and a system for practicing the method. The method utilizes self-protecting software code. Armed internally with self-defensive mechanisms, a self-protecting software program is tamper-resistant. Whenever its integrity is compromised, a self-protecting software program may become unusable due to software program crashes or other errors, or may generate subtle errors that do not immediately result render the program unusable but still result in incorrect software program execution. A self-protecting software program also may be able to repair itself to restore the integrity of its damaged code. The system comprises a computer program for automatically adding self-protection features to a software program.

Abstract: The most annoying aspect of software development is debugging. We don't mind the kinds of bugs that yield to a few minutes inspection. The bugs we hate are the ones that show up only after hours of successful operation, under unusual circumstances, or whose stack traces lead to dead ends. Fortunately, there's a simple technique that dramatically reduces the number of these bugs in our software. It won't reduce the overall number of bugs, at least not at first, but it'll make most defects much easier to find. The technique is to build our software to "fail fast".