This document discusses legacy and long-running projects. It defines a legacy system as an old technology that continues to be used because it still meets user needs, even though newer technologies are available. It notes that long-running projects of over 2 years duration can be considered legacy. The document provides advice on when and how to rewrite legacy systems, including ensuring the new technology is mature and the team is ready. It also discusses challenges of maintaining motivation for teams on legacy projects and paying off the accumulated technical debt over time.

1. Legacy / long running
projects
RubyConfLT 2012

2. def
"A legacy system is an old method, technology,
computer system, or application program that
continues to be used, typically because it still
functions for the users' needs, even though
newer technology or more efficient methods of
performing a task are now available." (Wikipedia)

3. def
Long running: > 2 years

4. def
Reality: long running =~ legacy

5. important!
technology
+
team

6. important?
technology
+
team
manage ment

7. technology: upgrade
worth total rewrite?
=~
to be or not to be

8. technology: rewrite

9. technology: rewrite
unless...

10. technology: rewrite
● 50% rule
● clear legacy system requirements
● new technology mature enough & team ready
● benefits/costs ratio
● customer understands what's going on (...)

11. technology: rewrite
Good (famous) examples:
● Mac OS -> OS X
● Minix -> Linux
● PHP 1 -> PHP 2

12. technology: rewrite
Good (famous) examples:
● Mac OS -> OS X
● Minix -> Linux
● PHP 1 -> PHP 2
● UBB -> vBulletin
● Netscape -> Mozilla
● ...

13. technology: rewrite
● integration tests
● prioritize!
● be ready to support legacy system
● simplify
● migrate data early
● rewrite piece-by-piece
● usually takes longer than expected

14. technology: technical debt
"Like a financial debt, the technical
debt incurs interest payments,
which come in the form of the extra
effort that we have to do in future
development because of the quick and
[1]
dirty design choice."
[1] http://martinfowler.com/bliki/TechnicalDebt.html

15. technology: technical debt
Main diff from short
period projects:
technical debt matters

16. technology: technical debt
Main diff from short
period projects:
technical debt matters
A LOT

17. technology: technical debt
Impact on team &
development speed

18. hard part: team
As always with HR:
difficult to measure

19. team: motivation
● lack of "hot" tech stuff
● high level of sh*t (everything needs to be
fixed!..)
● lack of challenge in well known field
● routine, routine, routine

20. team: motivation
side projects
IS-A-MUST

21. team: motivation
side projects
IS-A-MUST
even if forced

22. team: motivation
hackathons
startup weekends
conferences

23. team: motivation
scoped(freedom)
to choose tech

24. team: technical debt
pay your debt in time.

25. team: motivation
collective code
ownership
at least weak code ownership

26. team: motivation
adequate attention to
non-tech problem
solving (universal)

27. team: motivation
if a product has some fans
(hopefully),
forward/communicate love
letters to the team

28. return
1. technology matters as much as it matters to
the TEAM
2. changes are and must be inevitable
3. way of recharging the batteries must be
developed to get rid of long run exhaustion
4. ...
5. profit!

29. end
+Vidmantas Kabošis @vidmantas
vidmantas@kabosis.lt
vidmantas.kabosis.lt
slides: bit.ly/legacy-long-running-projects
Questions?