DevBoss May 2019 Presentation
- 2. Schedule for this evening ● 6.00pm - Networking ● 6.30pm - Welcome and Introduction: Lewis Horwell, Corecom Consulting ● 6.40pm – Presentation from Keith Williams, Software Development Manager, IRIS Software ● 7.30pm - Buffet and Refreshments ● 8.00pm - Group Discussions ● 8.30pm - Refreshments and networking www.corecomconsulting.co.uk
- 4. Hi, I’m Keith! • Development Manager for Cascade HR • Currently modernising Cascade • Long history of creating legacy messes https://www.iris.co.uk https://www.cascadehr.co.uk
- 7. Agenda Why transform? How to transform? Case studies
- 8. What is transformation? Technical Language shift New architecture Cleanup Infrastructure Hosted to cloud Desktop to web Web to app Product Bespoke to SaaS Feature pivot UX revamp
- 9. Examples • Rewrote from JSP to Angular • Upgraded to .NET Core • Moved from desktop to the web • Replaced Access with SQL Server • Migrated to the Cloud • Moved to hosted SaaS model
- 11. WHY? What is legacy software, and why do we need to transform it?
- 12. Why not?
- 13. Commercial reasons App is End-of-Life Regulatory environment Cost doesn’t justify benefits
- 14. Bad technical reasons Following the latest fad Developer ego Lack of interest in the business
- 15. OK… WHY?
- 16. Reasons to transform Recruitment Retention Security Performance Productivity Maintainability Operability Features
- 17. The risks of NOT changing STAGNATION CULTURE COMPETITION
- 18. HOW? Strategies for legacy transformation
- 19. Pre-flight checklist Get business buy-in 1 Survey your portfolio 2 Source control 3 Set up CI/CD pipeline 4
- 20. Clear the dead wood • Marie Kondo your codebase • If it never went live, it’s going in the bin • Break up mono-repositories if possible • Aggressively target code “noise”
- 21. Find some edges • Utility apps, customer portals, mobile sites • Split off, refactor • Choose the smallest one, try a rewrite • Proving ground for new tooling
- 23. The Fixer-Upper
- 24. Do the maintenance • Upgrade dependencies • Remove dead code • Refresh styles • Pay down technical debt
- 25. Trade-offs PRO • Low up-front cost • Keep the lights on • No customer migration • Deliver as BAU • Quick returns CON • Core tech debt remains • Can’t fix a broken model • Still the same tech • Still the same app
- 26. Case study: Ultimate Manager • ASP.NET WebForms application • Rotting since 2010 • Upgrade to .NET 4.7 • Update all dependencies • Lift-and-shift to Azure PaaS • 3 months to market
- 27. If the tech isn’t that bad, and the app is stable, maybe it just needs some TLC
- 28. The Strangler
- 29. Side-by-side • Plan and build a new architecture • Start writing side-by-side • Small, incremental deliveries • Slowly “strangle” the legacy app • Maintain backwards compatibility
- 30. Trade-offs PRO • No impact on users • Iterative improvement • Continual feedback • No customer migrations • Clean new architecture CON • Can’t fix a broken model • Can’t fix broken data • Compromise for compatibility • Split dev resources • Two codebases to maintain
- 31. Case study: Cascade “Novo” • Classic ASP/ASP.NET WebForms app • 2.7 million LoC • New ASP.NET Core + Angular app • Modern service-based architecture • Dependency on common database • 6 months to EA, 12 to market
- 32. If the tech is bad, but the data is sound, make a new view of the data
- 33. The Big Bang
- 34. Nuke the site from orbit • File New Project • New model, new architecture, new code • One big upgrade, no going back • Reimagine product from ground up
- 35. Trade-offs PRO • Clean new architecture • New model to suit business • Easier to recruit developers • Faster than Strangler CON • Long wait for pay-off • Must migrate customers • Must admit old app is EOL • Split dev resource • Legacy distractions • Easy to underestimate • Risk of solving old problems
- 36. Case study: Sunrise • ODIN: Classic ASP/COM app, 1 million LoC • Sunrise: Ground-up rewrite, no shared code or data • Migrate existing customers one by one • ASP.NET MVC + Azure PaaS architecture • 3 years to market
- 37. If the tech is bad, and the app doesn’t suit the business, you might as well re- write it from scratch
- 38. QUESTIONS?
- 41. “How do you transition Senior Engineers into leadership roles?” www.corecomconsulting.co.uk Discussion 1:
- 42. “What are the best approaches to gain buy-in for change?” www.corecomconsulting.co.uk Discussion 2:
- 43. “When working in an agile environment, how do you avoid too many meetings and not enough coding?” www.corecomconsulting.co.uk Discussion 3:
Editor's Notes
- Hi - I'm Keith, and I'd like to start with a confession: During my 16 years in this industry, I have created many, many legacy applications I've build PHP monstrosities and Access nightmares. Even the apps that I thought were cool and cutting edge in 2006 are now clunky WebForms and WCF graveyards. The tech that I advocated as new and exciting in 2010 is now just so much technical debt that will never be paid down.
- First, let's look at when you might NOT want to transform an app