Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Legacy Improvement - Done Right

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!

Dr. Gernot Starke

October 14, 2021
Tweet

More Decks by Dr. Gernot Starke

Other Decks in Programming

Transcript

  1. Problems in complicated system (0) • taste • price •

    appearance • location (of restaurant) https://flic.kr/p/6xuSMU
  2. Problems in complicated system (1) • taste • temperature •

    consistency • popularity • purchase price
  3. Problems in complicated system (2) Nutritional value: carbs, protein, fat,

    vitamins drugs, contamination, poison, radioactivity https://flic.kr/p/bDGDMY
  4. Kids... • really nice! • narrow focus • limited field

    of vision • driven by short-term desires
  5. 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...
  6. 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
  7. Metrics • coupling / dependencies • code complexity • performance

    • … • errors per component • Know-How per component • change frequency • … good better
  8. Telco: • Management measures (Java-) system with red/yellow/green (CAST Application

    Intelligence Platform) • >70% implemented in XSLT, • not measured by CAST
  9. VENOM External Interface Hell „Standard“ supplier Suppler API „Custom“ supplier

    >200 >200 point2point interfaces „Standard“ craftsmen „Custom“ craftsmen Craftsmen API ~35
  10. (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
  11. Clean Code + Bad Persistence ... (500) ... (300) ...

    (400) ... (400) ... (400) relational DB, „done wrong“
  12. 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
  13. 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!
  14. 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?
  15. 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
  16. 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“
  17. 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
  18. 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.
  19. 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