Lifeware

1. Lifeware • Spin off from Credit Suisse Life in 1999 • IT • Actuarial Department • Production • Offering full ASP for life insurance companies • Credit Suisse – Winterthur [CH] • LV1871 [D] • Helvetia – Patria [D] • Coop – National [CH • Convia [CH] • PrismaLife [D,A,CH] • 15 people

2. Lifeware and XP • Using Xp from start • Development Environment • Using VisualWorks Smalltalk • Database • Gemstone Oodbms

3. Testing • Current situation • 8000 tests • 17 minutes to run • 50% code, 50% tests • Test ~ Documentation • Executable • Up to date • Transition to testing @ Credit Suisse

4. Testing (2) • At the beginning you have the impression that the tests are important, but do not deserve so much attention and maintenance as the code itself • Writing tests is an order of magnitude more difficult than writing code • Testing UI is more difficult than testing model. It took 2 years but now we found a satisfactory solution to test first web interfaces. • Every bug we find has a special test suite

5. TestFirst • Adding tests to your development process is not so difficult • More difficult is the switch to test first • never write code in the browser • write code only in the debugger after running a test • Stop thinking ahead

6. Refactoring • Syntactic Refactoring • Examples • Unused class, variable, methods • Long methods • When: twice a day, before integrating • Semantic Refactoring • Examples • Parallel Hierarchies • Testing user interface • When: when you have the right idea

7. Transition to refactoring • Transition is not so difficult • Full adoption is more difficult • Using the refactory browser you can reach a new level of productivity

8. Continuous Integration • Every pair integrates once a day • 6 pairs * 2 ~ 12 integration/day • More often you integrate less problems you have

9. Small releases We release 2 times a week all productions we have to migrate the objects in production Transition: until you do not have enough test extremely dangerous After going live at CS, I developed 2 months without integrating. It took 3 additional months to put the changes in production

10. Pair programming • Fastest way to disseminate know-how • You have always at least 2 people knowing some part of the system • If code review is a good idea, doing it all the time is even better • Releasing the pig .... is more difficult, because someone is always watching you • Taking the wrong direction is minimized, even for experienced people

11. Pair Programming @ Lifeware • Worst followed practice • Remote (2 development centers with 7 people each) • 10-30% production • Not only pairing, but also switching the pairs

12. Code ownership • Everybody can change anything • Precondition for refactory • Piecemeal cleaning

13. myXP Analysis Design Implementation Testing Production Development Production 10 years ….. 2-3 months

14. XP lessons learned • XP puts the bar very high • XP can get out of control easy • Example: Refactory under time contraints • Example: Long methods • XP seems very anarchic, but requires a lot of discipline

15. XP in production • The practices of XP are important in the development phase, but becomes unavoidable in production • We change the production daily instead of annually

16. XP & your Customer • XP requires a different relationship with the customer. Fixed price, fixed scope contracts are simply not working. You have to reinvent the relationship with your customer. Some ideas • Optional scope contracts • Pay per use

17. XP in other fields • We transferred XP practices to control the quality of the production (life insurance policy management) • Daily alerters (Testing) • Weekly closures instead of annual closures (Small Releases)