Slide 1

Slide 1 text

The Past, Present and Future of Technical Debt Learning from the past to prepare for the future Technical Debt 2018 Gothenburg, May 2018 Eoin Woods Endava @eoinwoodz

Slide 2

Slide 2 text

Background Eoin Woods • Endava’s CTO, based in London • 10 years in product dev - Bull, Sybase, InterTrust • 10 years in capital markets applications - UBS and BGI • Software engineer, then architect, now CTO • Author, editor, speaker, community guy I’ve had a lot of technical debt

Slide 3

Slide 3 text

What is Technical Debt?

Slide 4

Slide 4 text

Defining Technical Debt • “Not quite right code which we postpone making it right” – Ward Cunningham • “The obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term” – Steve McConnell • “Compromises made in the implementation of a piece of software that are likely to limit how it can be used or changed later” – Eoin Woods

Slide 5

Slide 5 text

(Some) Types of Technical Debt Intra-Module Inter-Module Testing User Experience Data Operation Platform + Functional

Slide 6

Slide 6 text

Why Do We Care? • Reduces speed of delivery • Reduces options for change • Reduces morale in the team • Reduces reliability • Increases cost of change • Increases cost of operation REDUCES OUR RETURN ON INVESTMENT

Slide 7

Slide 7 text

TECHNICAL DEBT IS OFTEN WHAT PREVENTS US MEETING A FUTURE NEED IN A TIMELY AND COST EFFECTIVE MANNER

Slide 8

Slide 8 text

Like Death and Taxes

Slide 9

Slide 9 text

Technical Debt Through the Ages

Slide 10

Slide 10 text

5 Ages of Software Systems Intelligent Connected (2020s) Internet is the System (2010s) Internet Connected (2000s) Distributed Monoliths (1990s) Monolithic (1980s)

Slide 11

Slide 11 text

Monolithic Technical Debt • Procedure tangles • GOTO spaghetti • Data incoherence Advances • Structured Programming • Early metrics • Early analysis tools Structuring of computer programs

Slide 12

Slide 12 text

Distributed Monoliths Technical Debt • Tiering confusion • all in the UI, all in the DB, … • Spaghetti database • Monster data models Advances • Emergence of the metaphor • Refactoring • Commercial tools The rise of client/server and architectural style

Slide 13

Slide 13 text

Internet Connected Technical Debt • Unsuitable platforms • Unsustainable operation • One-man deployment “pipeline” • Quality property hacks Advances • Software architecture • Patterns and platforms for large-scale systems • Open source tools Mass market scaling and explosion in software architecture

Slide 14

Slide 14 text

Internet as the System Technical Debt • External service dependencies • Microservice choreography • Data replication & duplication Advances • API descriptions • Runtime tracing & visualisation • Containers & platforms Everything is a service, architecture dynamic & packaged

Slide 15

Slide 15 text

New Sources of Technical Debt • Architecture hidden in the network (e.g. microservices) • Digital channels => constant functional change • Shift to unstructured and replicated data • Rapidity and self-service of cloud platforms • New types of code (“X as Code”) • Rapid tech stack evolution (e.g. framework churn)

Slide 16

Slide 16 text

Current Technical Debt in Practice • Ubiquitous term • General focus on code, sometimes tests • Data, platform, operational debt often not recognised • Some teams actively manage the debt • Many just talk about it • “Everyone” has a mountain of it • No widely adopted reasoning frameworks • Looming “new debt” problems don’t get much attention

Slide 17

Slide 17 text

On the Future

Slide 18

Slide 18 text

Intelligent Connected

Slide 19

Slide 19 text

Intelligent Connected Technical Debt • Unknown connected devices • Data needed for “intelligence” • ML models Advances (Needed) • Better IoT security & mgmt.? • More on data & algorithms? • Self-explaining AI? Data, algorithms, “intelligence”, emergent architecture

Slide 20

Slide 20 text

To Conclude

Slide 21

Slide 21 text

Conclusions • Our past can point to the future • Monolithic complexity led to structure and metrics • Distributed Monoliths brought a metaphor & refactoring • Internet Connected systems needed architecture & triggered open source tooling • Each era has tried to manage the debt it finds itself with … often with limited impact

Slide 22

Slide 22 text

Conclusions • Internet as the System brings its own problems too: • External dependencies (services) • Microservice dependencies • Data replication & duplication • New types of code and platform • Response is largely project-by-project • containers? runtime tracing? api doc techniques? ... • Technical Debt practice often lags the need by years!

Slide 23

Slide 23 text

Conclusions • What about Intelligent Connected systems? - We’re not great at ”data debt” but these systems depend on it - AI debt still not understood but will become a standard feature - Devices bring lots of debt but we struggle with today’s challenge • We’ve got some work to do … - We can see what is coming - This time could research and practice predict the debt and think about managing it … before we have a lot of it?

Slide 24

Slide 24 text

THANK YOU Eoin Woods Endava [email protected] @eoinwoodz

Slide 25

Slide 25 text

Picture Credits • Erik Pitti – S360, slide 11 (Flickr) • Tech Republic – S370, slide 11 • Tim Dorr – server rack, slide 12 (Flickr) • JasonTheGreat – Sun server room, slide 13 (Flickr) • Intel Free Press – Intel server room, slide 14, 15, 16 (Flickr) • Geralt – IoT background, slide 18, 19