1 / 8

Fixing Systems that Ain’t Broken

Fixing Systems that Ain’t Broken. Dr. Roberto Sasso Feb. 7 th 2003. “Wear and tear” of software. “Good” software should work forever Time has a definite effect on software It is not quite like wine In 1971 maintenance was 30% of effort In 2003 maintenance is close to 90%.

tallys
Download Presentation

Fixing Systems that Ain’t Broken

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Fixing Systems that Ain’t Broken Dr. Roberto Sasso Feb. 7th 2003

  2. “Wear and tear” of software • “Good” software should work forever • Time has a definite effect on software • It is not quite like wine • In 1971 maintenance was 30% of effort • In 2003 maintenance is close to 90%

  3. The future of software • Is software maintenance the future of programming? • Will we keep writing the same applications over and over again? • Will the software world become saturated? • Should we advise our children to study law?

  4. When should software be fixed? • When all hell breaks loose? • When it stops working? • When the first bug is found? • When user demands overwhelm maintenance personnel?

  5. Analogies are missleading Things made of atoms are inherently different!

  6. Software fixing software • Since the world insists in changing at an ever increasing pace, software must be flexible • Software transformation seems to be the key • Not magic • Not rocket science • Artificial Intelligence (better than Natural Stupidity)

  7. Software “use by” date • We need to know well in advance when the software will stop being useful • IF we could measure software flexibility or mantainability... • THEN its a piece of cake • ELSE we must use financials to estimate the use by date

  8. When should software not be fixed? • When its opaque and obscure (and ugly!) • When it performs its funcionality wrong • When it crashes only when its running • When the business changes 180 degrees • When its broken!

More Related