Legacy Improvement - Done Right

As software developers, we spend most our time maintaining existing systems – under time and budget pressure. Building new business functionality tends to get more difficult, expensive and risky over time due to increasing size, growing complexity and lack of overview. Although we complain about technical debt, lack of innovation and the architectural deficits of historically _grown_ software, we often patch, fix or hack symptoms instead of curing the root causes of these problems. In this talk you’ll get an overview of the systematically improving or modernizing your system. The approach shown here is based upon the established idea of identifying the specific problems first, before changing or modifying a system. We will take a closer look at different areas of investigation, such as architecture, code, technology, quality requirements, application data plus development and rollout processes, in an iterative breadth-first analysis. For each area of investigation I give examples and show methodical tools for effective and practical use. Afterwards you’ll get an overview of strategical and tactical approaches to specific improvements, based upon the problems and risks found during analysis. The presentation is aimed at software development teams, architects, product owners and technical management. Everything I present in this talk has been proven in software and system projects and reviews I conducted over the last couple of years in various industries – so expect some (anonymized) practical examples!

Transcript

1. Software Improvement Done Right Dr. Gernot Starke
2. Dr. Gernot Starke INNOQ Fellow üArchitecture-Improver üCoach, Trainer ü arc42, aim42 ü iSAQB
3. There should be only ONE reason to change:
5. Change to add value...
6. • actionism • cargo cult • longing to try technology XY No:
7. Add value by removing problems
9. Complicated systems https://flic.kr/p/7XAjXu
10. Problems in complicated system (0) • taste • price • appearance • location (of restaurant) https://flic.kr/p/6xuSMU
11. Problems in complicated system (1) • taste • temperature • consistency • popularity • purchase price
12. Problems in complicated system (2) Nutritional value: carbs, protein, fat, vitamins drugs, contamination, poison, radioactivity https://flic.kr/p/bDGDMY
13. Problems in complicated system (3) Logistics & storage of ingredients https://flic.kr/p/pnVsxu
14. Kids... • really nice! • narrow focus • limited field of vision • driven by short-term desires
15. Pro Beginner •overview by methodical assessment •objective priorities •balance between strategy and tactic
16. Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic e valuate analyze improve
17. architecture improvement method https://aim42.org
18. Breadth-first search Stakeholder Context Quality Architecture Code Runtime Data Tests Processes Infrastructure Security ....
19. Access All Areas Postbank Dortmund Postfach 44132 Dortmund
20. Breadth-first search 1. Stakeholder 2. (Overall) structure 3. Code details 4. Cohesion 5. Context 6. Qualities 7. Development process 8. Persistence 9. Technology 10. Infrastructure examples... examples...
21. Stakeholder know many problems (+ solutions).
22. Overall structure Does component structure fit to problem? Too many dependencies?
23. Level-1: Component Disorder Sales Frontend Private + Corporate Configurator Shell Client Contracts UDS (User Data Service) Order & Fullfillment Vouchers & Rebates eGov Shop Sales & Contracts Archive External Partners Price Management Data Warehouse Marketing & Sales Campaigns Atlas Customs & Logistics Pricing Engine Sales Backend Private+Corp Hodor Optical Archive Post-Sales Services Security Extensions Legend: Java PHP Python C/C++ Hask ell Cobol PL/ SQL Flash HTML/ JS Sales Backend eGovernment
24. Code details Hotspots and other smells...
25. Metrics • coupling / dependencies • code complexity • performance • … good
26. Metrics • coupling / dependencies • code complexity • performance • … • errors per component • Know-How per component • change frequency • … good better
27. Telco: • Management measures (Java-) system with red/yellow/green (CAST Application Intelligence Platform) • >70% implemented in XSLT, • not measured by CAST
28. complex code that‘s modified often. Find Hotspots
29. Context External interfaces
30. VENOM External Interface Hell „Standard“ supplier Suppler API „Custom“ supplier >200 >200 point2point interfaces „Standard“ craftsmen „Custom“ craftsmen Craftsmen API ~35
31. Cohesion (does it belong together?)
32. (bad) Cohesion UDS (User Data Service) Order & Fullfillment Vouchers & Rebates Sales & Contracts Archive Price Management Marketing & Sales Campaigns Atlas Customs & Logistics Pricing Engine Sales Backend Private+Corp Sales Backend eGovernment determines prices calculations & data ALSO relevant for pricing
33. Analyse application data / data structures Databases, data-structures, distribution, replication, etc
34. Clean Code + Bad Persistence ... (500) ... (300) ... (400) ... (400) ... (400) relational DB, „done wrong“
35. Technology Appropriate? Outdated? Mis-used?
36. https://www.youtube.com/watch?v=xL4 0UN5p6IY #3
37. https://www.youtube.com/watch?v=xL4 0UN5p6IY
38. Example: Use of Rule-Engine • Review identifies deviation from standard (concerning loading strategy of Working-Memory) • • (Standard) assumption: few but huge data sets • Reality: many but very small data sets
39. breadth first search Metrics Structure Application Data Quality Security Processes Code Technology etc.
40. Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic aim42
41. Our status: LARGE number of problems
42. Breadth-first search Stakeholder Kontext Qualität Architektur Code Laufzeit Daten Tests Prozesse Infrastruktur Security .... H ? H H M M ? M H H H M ? ? ? M M M M H M M ? H H M M H H M M ? H M M M M H H Priorities needed!
43. Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic aim42
44. Proposal: Map problems to money
45. prioritize / estimate problems roughly estimate... trivial problems
46. Issue Cost Improvement Cost > Only change something if problem is more expensive than its solution
47. Estimation: Fundamentals... Term Description Subject What do we estimate Unit Time, money, effort, pain (cost) factor What influences the subject? Assumptions What do we estimate/guess about these factors Observation Metrics, counts etc. of single factors Probability How sure are we of these numbers?
48. Pro •overview by methodical assessment •objective priorities •balance between strategy and tactic aim42
49. Verbesserung mit Tagesgeschäft day-to-day development Practices Practices time Approaches Practices Practices Practices Practices Scheduling Improvements
50. Categories of long-term improvements... Throw away & rebuild reduce size Improve some parts improve internal structure & cohesion «category» Long-Term Improvement Approach «category» Rewrite «category» Restructure «category» Data Migration «category» Brainsize «category» Improve Modularization «category» Supporting Patterns Improve processes or technology
51. Change by Extraction 2 1 Client Flawed (incohesive) System Client „other“ other features Client Flawed System Client „other“ other features Better other features Client (reduced) Flawed System Client „other“
52. Change by Split 1 2 3 Client Type 1 Flawed System Client Type 2 Client Type 1 Flawed System Client Type 2 Flawed System Client Type 1 Reduced to Type 1 Client Type 2 Reduced to Type 2 New Type 1 System Client Type 1 Client Type 2 New Type 2 System
53. Change by Switch („Strangulizer“) Original by Paul Hammant: http://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
54. Decorating Collaborator Client Code Flawed Supplier «use» Client Code Flawed Supplier „Proxy“ «use» «delegate» 1. 2. New functionality Client Code Flawed Supplier „Proxy“ «use» «delegate» «decoration» 1. 2. 3.
55. Beware of the database... it‘s usually harder to improve than the code
56. Summary e valuate analyze improve https://aim42.org 1. Identify problems 2. Prioritize 3. Change aim42
57. Thanx. Gernot Starke gernot.starke@innoq.com Twitter: @gernotstarke www.innoq.com
58. Headline Cum sociis natoque penatibus et magnis dis parturient montes. 14.000 Requests pro Sekunde
59. Headline Cum sociis natoque penatibus et magnis dis parturient montes. 14.000 Requests pro Sekunde
60. Separate separate things Join things that belong together
61. Unser Kernteam FRONTEND PRODUKTENTWICKLUNG FRONTEND PRODUKTENTWICKLUNG FRONTEND PRODUKTENTWICKLUNG FRONTEND PRODUKTENTWICKLUNG Heribert Innoq Proxy-Pro Heribert Innoq Proxy-Pro Heribert Innoq Proxy-Pro Heribert Innoq Proxy-Pro
62. Text Text Text Text Text Text