Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Long Life Software

6,933 views

Published on

Civil engineers build structures to last. Aerospace engineers build airplanes for the long haul. Automotive engineers build cars to last. How about software engineers?

Not all of software needs to be engineered for long-life, but in some systems the predicted market span dictates we plan for the future. How can we do this, given the uncertainties in the technology industry?
What can we learn from the past?
How can we take informed bets on technologies and plan for change?
This session will cover some of the important technical considerations to make when thinking about the long term.

Published in: Software, Technology
  • Be the first to comment

Long Life Software

  1. 1. Mike Long
  2. 2. Why are we here? • For some systems the predicted market lifetime dictates we plan for the long term. How can we do this, given the uncertainties in the technology industry? • What can we learn from the past? • How can we take informed bets on technologies and plan for change?
  3. 3. Built to last: why long life software matters* • Code has the potential to last forever • Investments in intellectual property can provide returns year-on-year • Rewriting IP due to technical failures is a crime *This only applies to software that has a proven market and a long expected shelf life. In a similar manner, gold-plating software of unproven value is equally criminal
  4. 4. Disclaimer: I have no idea what I’m talking about. Test these ideas for yourself.
  5. 5. Goldilocks Engineering
  6. 6. The Tay Bridge
  7. 7. The Tay Bridge: under-engineered “a single-track lattice design, notable for lightness and low cost. Its sudden collapse in a high wind … was one of the great engineering disasters of history”
  8. 8. The Forth Bridge
  9. 9. The Forth Bridge: over-engineered …legislation insisted that the Forth bridge should "enjoy a reputation of not only the biggest and strongest, but also the stiffest bridge in the world"
  10. 10. Boeing 747
  11. 11. Boeing 747: Goldilocks-engineered
  12. 12. Boeing 747: Goldilocks-engineered • Adaptable to new uses • Resilient in design • Decoupled from suppliers
  13. 13. Learning from the past How do we make software that lasts? How do we avoid over-engineering?
  14. 14. Towards a theory of natural selection
  15. 15. Copying is the only long term survival tactic
  16. 16. Genes can reproduce at the expense of the organism
  17. 17. Adaptations contribute to the fitness and survival of individuals
  18. 18. Variation under domestication and under nature
  19. 19. Size matters, but how?
  20. 20. A theory
  21. 21. Goldilocks Engineering in software
  22. 22. // The specific idiot in this case // is Office95, which likes to free // a random pointer when you start // Word95 from a desktop shortcut. // we are such morons. Wiz97 underwent // a redesign between IE4 and IE5 // HACK ALERT, believe it or not // there is no way to get the // height of the current // HACK ON TOP OF HACK ALERT, Year Operating System SLOC 1993 Windows NT 3.1 5 million 1994 Windows NT 3.5 8 million 1996 Windows NT 4.0 12 million 2000 Windows 2000 29 million 2001 Windows XP 45 million 2003 Windows Server 2003 50 million
  23. 23. • Adaptable to new uses • Resilient in design • Decoupled from suppliers
  24. 24. Three survival tactics
  25. 25. Compiling Keep the software alive
  26. 26. Choose 3rd Parties well
  27. 27. Languages Fortran 1957 Lisp1958 Pascal 1968 C 1972 (C with Classes ) C++ 1979 Java 1990 Basic 1964 C# 2000 Prolog 1972 Python 1991 Managed C++ 2000C++/CLI 2005
  28. 28. Source code lives forever • Not scary: – Code you wrote – Licensed source code • Scary: – Pre-compiled binaries – Frameworks and tools – Operating systems – Libraries
  29. 29. Design for change • Valuable stuff: – Algorithms (computations/business rules) – Data structures – Protocols • Temporary stuff: – Interfaces – Runtimes
  30. 30. The good stuff lasts as long as the crap • Code can last because: – it’s so useful – no-one understands it enough to change it • So make it good! – cheaper in the long run – more likely to improve
  31. 31. Some things wont change
  32. 32. Use uncertainty as a driver
  33. 33. Push the technology out Hexagaonal Architecture Clean Architecture
  34. 34. Depend in the right direction UI Program
  35. 35. Depend in the right direction UI Program
  36. 36. Depend in the right direction Program UI DB Network
  37. 37. Remember Gall’s Law “A complex system that works is invariably found to have evolved from a simple system that worked.” • Underspecify • Avoid the second systems effect
  38. 38. Compiling Keep the software alive
  39. 39. Binary Secrets
  40. 40. Reproducibility = + +
  41. 41. Beware black boxes
  42. 42. Keeping the knowledge alive • Good: documentation – Best in plain text and in your version control • Better: in the heads of people – Linux is an example • Best: Good tests (the ones that assert requirements rather than implementation details) – Exemplar executable documentation always in sync with your code and never forgotten
  43. 43. Choose 3rd Parties well
  44. 44. I, pencil
  45. 45. Reliabilities are Liabilities • The first rule of software club: – “On a long enough timeline, the survival rate for every third party drops to zero” • Plan to out live your dependencies – Platforms – Runtimes – Compilers – Libraries • Avoid single vendor technologies
  46. 46. Historical dead ends • Things that are typically unstable over time: – Display technologies – Persistence (Database access and structure) – Tools – Model Driven Development – New programming languages – Middleware stacks (CORBA, COM, …)
  47. 47. Be wary of new technology • Best practices are not yet established • Training will be pioneering • Stickiness not guaranteed
  48. 48. A story • Compiler vendor acquired and product discontinued • Closed source RTOS • Poor debugging tools • >6 months investigation • >1yr to production fix …probably the best bug fix in the world
  49. 49. Long life software
  50. 50. Where does that leave us? • Design for cheap copies, not reuse • Source will survive longer than binaries • Be smart about your dependencies
  51. 51. Let’s talk! @meekrosoft http://www.flickr.com/photos/ngk/4331399573/

×