long life software

Long-L

ife

Sof

twar

e

Mike Long

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?

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

Disclaimer: I have no idea what I’m talking about. Test these ideas for yourself.

Goldilocks Engineering

The Tay Bridge

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”

The Forth Bridge

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"

Boeing 747

Boeing 747: Goldilocks-engineered

Boeing 747: Goldilocks-engineered

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

Learning from the past

How do we make software that lasts? How do we avoid over-engineering?

Towards a theory of natural selection

Copying is the only long term survival tactic

Genes can reproduce at

the expense of the organism

Adaptations contribute to the fitness and survival of individuals

Variation under domestication and under nature

Size matters, but how?

A theory

Goldilocks Engineeringin software

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

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

Threesurvivaltactics

SOURCE

Compiling

Keep the software alive

Choose 3rd Parties well

SOURCE

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

Source code lives forever

• Not scary:– Code you wrote– Licensed source code

• Scary:– Pre-compiled binaries– Frameworks and tools– Operating systems– Libraries

Design for change

• Valuable stuff:– Algorithms (computations/business rules)– Data structures – Protocols

• Temporary stuff:– Interfaces– Runtimes

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

Some things wont change

Use uncertainty as a driver

Push the technology out

Hexagaonal Architecture Clean Architecture

Depend in the right direction

UI

Program

Depend in the right direction

UI

Program

Depend in the right direction

Program

UI

DB

Network

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

Compiling

Keep the software alive

Binary Secrets

Reproducibility =

+ +

Beware black boxes

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

Choose 3rd Parties well

I, pencil

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

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

Be wary of new technology

• Best practices are not yet established• Training will be pioneering• Stickiness not guaranteed

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

Long life software

Where does that leave us?

• Design for cheap copies, not reuse• Source will survive longer than binaries• Be smart about your dependencies

Let’s talk!

@meekrosoft

http://www.flickr.com/photos/ngk/4331399573/