Rebuild or Refactor? That is the question! (Techorama)

Sooner or later, you will encounter the question: Rebuild or Refactor? Software that has been in use for several years will inevitably cause issues. Maybe the software is hard to maintain, or perhaps it is difficult to add new features, which slows down development. Your development teams might spend more time fixing issues than adding new features, making changes both hard and expensive. Developers may suggest starting over because the software is unmaintainable, while the business pushes back to maintain velocity.

Regardless of the reason, the question will arise: Should we rebuild the software? How long will it take? And how much will it cost?

These are important and seemingly straightforward questions, but the answers are not always simple or concrete. There is more to consider than just time and resources.

In this session, we will explore this question in more detail. We will discuss some challenges and considerations involved in making the business decision to rebuild or refactor an application. Furthermore, we will explore how to proceed once the decision has been made.

Transcript

1. Rebuild or Refactor? That is the question! Starring Rene van Osnabrugge Xebia
2. REBUILD OR REFACTOR? • you have 20 years old code base • it is a mixture of c++ , .net 4,6, wpf and asp.net web forms • there is almost no documentation • you have a large user base • availability needs to be high 99.5% • there is almost no one that understands the code anymore • people walk away because of the difficult code • lots of bugs! 85% of time is maintenance
3. CONTENTS OF THIS SESSION • Why would someone ask this question? • What are the options for App modernization • Why and how would you choose the one or another? • How do you create a business case ? • What non-technical issues do you need to cater for?
5. Main reasons for modernizing Legacy applications
6. HOW TO DECIDE?
7. We cannot change anything. The mess is too big! We need a rewrite! The manager ASK DEVELOPERS
8. ASK MANAGEMENT I think a lot of the time when a developer shouts “technical debt” what they are really shouting is “code someone else wrote that I’d rather rewrite than understand”. Just refactor a bit!
9. PEOPLE ARE BAD INDICATORS • Peer Pressure • Time restrictions • Personal Prejudice • The past • Emotions • Motivations • Personality Traits
10. THEY SUFFER FROM COGNITIVE BIAS
11. CAN YOU MENTION AN EXAMPLE? • OVERCONFIDENCE BIAS • CONFIRMATION BIAS • ANCHORING EFFECT • OVERGENERALIZATION
12. CAN YOU MENTION AN EXAMPLE? • OVERCONFIDENCE BIAS • We have done this before, this time we can do it 2x faster • CONFIRMATION BIAS • I read about these projects using Azure that failed, cloud is not for us • ANCHORING EFFECT • I think we need 3 months, what do you think? • OVERGENERALIZATION • Refactor never solved issues before…
13. Let’s approach it from the rational side
14. The case for Refactor • Reduces Technical Debt Incrementally • Lower Risk • Preserves Business Continuity • Faster Time to Market • Familiarity with Existing Code • Cost-Effective • Avoids Scope Creep • Leverage Existing Features • Minimizes User Disruption
15. The case for Rebuilding • Severe Technical Debt • Outdated Technology Stack • Inability to Scale • Security Vulnerabilities • Business Needs Have Changed • Cost of Maintenance is Exceeding Value • Developer Bottlenecks • Better Modern Tools Available
16. We still need to be careful for the bias
17. THERE IS A COMMON DENOMINATOR
18. WHAT IS TECHNICAL DEBT
19. Compared to other industries
20. CAUSES FOR TECH DEBT • Time pressure • Misalignment • Passing of time • Business pressure • Lack of knowledge • Bad architecture decision • Human factors • Incorrect implementation • Lack of anticipation
21. HIGH TECHNICAL DEBT LOWER PRODUCTIVITY LOW CODE QUALITY PRESSURE TO INCREASE PRODUCTIVITY LOW MORALE & MOTIVATION VICIOUS CYCLE OF TD
22. We don’t have time We don’t Know how We deal with it later We shouldn’t have done that reckless careful deliberate unintended HOW DOES TD GROW?
23. ARCHITECTURAL TECHNICAL DEBT
24. THE PRESENT BIAS
25. What can we do to avoid it ? • Major refactoring • Cleaning sprints • Boy scout rule • Patching • Static Code analysis • Dedicated time in sprints • Code reviews
26. But is refactor enough?
27. THE BASAL METABOLIC RATE • Major refactoring • Cleaning sprints • Boy scout rule • Patching • Static Code analysis • Dedicated time in sprints • Code reviews
28. THE BASAL COST OF SOFTWARE ADDING A FEATURE HAS IMPACT ON: • TEAM CAPACITY DUE TO ADDED COMPLEXITY • COST TO MAINTAIN AND UPDATE
29. THE BASAL COST OF SOFTWARE
30. THE BASAL COST OF SOFTWARE
31. WHY THESE COSTS FOR FINISHED FEATURES? • need to know where the code is • need to know the dependencies in the codecase • need to update the tools/frameworks • compatibilty issues • regression • new joiners need to learn more
32. THE BASAL COST OF SOFTWARE
33. So rebuild then!
34. REMEMBER THIS ONE?
35. CONE OF UNCERTAINTY
36. you can ask almost any programmer today about the code they are working on. “It’s a big hairy mess,” they will tell you. “I’d like nothing better than to throw it out and start over.” a functioning application should never, ever be rewritten from the ground up. His argument turned on two points: • The crufty-looking parts of the application’s codebase often embed hard-earned knowledge about corner cases and weird bugs. • A rewrite is a lengthy undertaking that keeps you from improving on your existing product, during which time the competition is gaining on you. 6 April 2000 Things You Should Never Do, Part I – Joel on Software
37. CONE OF UNCERTAINTY
38. The conventional wisdom around rewriting software is that you should generally avoid it Netscape - Rewrite Failed Friendster - Rewrite Failed VS Code - Rewrite Succeeded, but side by side Basecamp - Rewrite Succeeded, but side by side Gmail & Inbox - 2 products, same backend Freshbooks & Billspring - High cost and `own` competitor
39. THIS IS WHAT WE KNOW FOR SURE
40. + REVENUE - RISK - COST BUILDING THE BUSINESS CASE
41. + REVENUE - RISK - COST COST TO MODERNIZE COST TO MODERNIZE REVENUE OPPORTUNITY OPERATING COST BENEFIT
42. RE* COST IS NOT ONLY RE* COST • REBUILD / REFACTOR COST • TIME / MATERIAL / PEOPLE • NON - REBUILD COST • WASTE • EFFICIENCY LOSS • MORAL • NRC = BUG FIX TIME + SUPPORT TIME + LOWER PRODUCTIVITY
43. BACK TO THE START • you have 20 years old code base • it is a mixture of c++ , .net 4,6, wpf and asp.net web forms • there is almost no documentation • you have a large user base • availability needs to be high 99.5% • there is almost no one that understands the code anymore • people walk away because of the difficult code • lots of bugs! 85% of time is maintenance
44. This was not (fun) fair! • But it happens all the time in your business • What would a rebuild cost me? • Shall we do Microservices or a monolith? • Shall we offshore this or do it inhouse? • Should we hire people or find consultants?
45. CRITICAL THINKING = KEY
46. Framing Effect • Decisions are influenced by how choices are presented • People tend to choose from the given options, overlooking alternatives. • The way information is framed (positive or negative) can alter perceptions of risk and benefits. • Better informed people make better choices
47. there are more then 2 options the 5 r model applies here as well • Rehost (Lift and Shift) • Refactor (Rearchitect) • Revise (Replatform) • Rebuild (Reengineer) • Replace (Rip and Replace) • Retire
48. USE THE PRESENT BIAS AS A COMPASS
49. REWRITE IS ESSENTIALY BIG BANG
50. Continuous Modernization (gartner) • Instead of a disruptive rip-and-replace approach, focus on continuous modernization to optimize legacy applications by addressing specific business obstacles. • Legacy applications often hinder business agility due to outdated design, closed systems, and aging components. • Identify and prioritize friction points, transform by modernizing specific components, and continuously refine and repeat the process. • Collaboration and Culture: Foster a continuous modernization culture involving both IT and business leaders to manage technical debt and align modernization efforts with business needs. Gartner Reprint
51. feature architecture bug Technical debt Positive negative visible invisible WHERE DO YOU SPEND MOST TIME?
52. “ANY ORGANIZATION THAT DESIGNS A SYSTEM WILL PRODUCE A DESIGN WHOSE STRUCTURE IS A COPY OF THE ORGANIZATION'S COMMUNICATION STRUCTURE”
53. “ANY ORGANIZATION THAT DESIGNS A SYSTEM WILL PRODUCE A DESIGN WHOSE STRUCTURE IS A COPY OF THE ORGANIZATION'S COMMUNICATION STRUCTURE” CONWAY’S LAW
54. UI EXPERTS ESB EXPERTS DB EXPERTS PROCESS EXPERTS
55. UI MIDDLEWARE DATABASE BPM
56. BIG MONOLITH WITH DEPENDENCIES SMALL AUTONOMOUS COMPONENTS
58. Who owns this page
59. Library Profile Recommendation Music Player
60. INVERSE CONWAY MANEUVRE
61. INVOICING DELIVERY INVENTORY
62. INVOICING DELIVERY INVENTORY
63. • Logical cohesion • Teams in multiple domains • 1 technologystack • Organisation domain • Team is owner of a domain • From A to Z • As isolated as possible
64. Each service its own choices Frontend integration Event bus
65. Each service its own choices Frontend integration NEW REBUILD REFACT OR Event bus REHOST REPLACE
66. PATTERNS TO GET THIS STARTED • BUBBLE CONTEXT • STRANGLER PATTERN • FEATURE TOGGLES
67. • GitHub Next | SpecLang • GitHub Copilot • LLM AND MAYBE USE AI?
68. The HINDSIGHT BIAS
69. WRAP UP • What is Refactor / Rebuild • The effect of Tech Debt • The basal cost of software • The role of bias • How to get started
70. Rene van Osnabrugge global consulting director rene.vanosnabrugge@xebia.com