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.

1. Mike Long

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. 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. Disclaimer: I have
no idea what I’m
talking about.
Test these ideas
for yourself.

5. Goldilocks
Engineering

8. The Tay Bridge

9. 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”

10. The Forth Bridge

11. 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"

12. Boeing 747

13. Boeing 747: Goldilocks-engineered

14. Boeing 747: Goldilocks-engineered
• Adaptable to new uses
• Resilient in design
• Decoupled from suppliers

15. Learning from the past
How do we make software that lasts?
How do we avoid over-engineering?

16. Towards a theory
of natural
selection

18. Copying is the only long term survival
tactic

19. Genes can
reproduce at
the expense of
the organism

20. Adaptations contribute to the fitness
and survival of individuals

21. Variation under domestication and
under nature

22. Size matters,
but how?

23. A theory

24. Goldilocks
Engineering
in software

26. // 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

27. • Adaptable to new uses
• Resilient in design
• Decoupled from suppliers

28. Three
survival
tactics

30. Compiling
Keep the software alive

31. Choose 3rd Parties well

34. 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

35. Source code lives forever
• Not scary:
– Code you wrote
– Licensed source code
• Scary:
– Pre-compiled binaries
– Frameworks and tools
– Operating systems
– Libraries

36. Design for change
• Valuable stuff:
– Algorithms (computations/business rules)
– Data structures
– Protocols
• Temporary stuff:
– Interfaces
– Runtimes

37. 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

38. Some things wont change

39. Use uncertainty as a driver

40. Push the technology out
Hexagaonal Architecture Clean Architecture

41. Depend in the right direction
UI
Program

42. Depend in the right direction
UI
Program

43. Depend in the right direction
Program
UI
DB
Network

45. 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

46. Compiling
Keep the software alive

47. Binary Secrets

48. Reproducibility =
+ +

49. Beware black boxes

51. 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

52. Choose 3rd Parties well

53. I, pencil

54. 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

55. 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, …)

56. Be wary of new technology
• Best practices are not yet established
• Training will be pioneering
• Stickiness not guaranteed

58. 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

59. Long life software

60. Where does that leave us?
• Design for cheap copies, not reuse
• Source will survive longer than binaries
• Be smart about your dependencies

61. Let’s talk!
@meekrosoft
http://www.flickr.com/photos/ngk/4331399573/