Stefan Priebsch

Seven Myths, Three Reasons, One Goal

Is a complete rewrite your only option for legacy code? This talk dismantles seven common myths holding you back.

Seven Myths, Three Reasons, One Goal
#1about 9 minutes

Viewing your IT landscape as an evolving city

The history of Alexandria illustrates how software systems, like cities, are built on existing foundations and evolve over time.

#2about 5 minutes

Why legacy code is so difficult to understand

Legacy code often fails to communicate business intent and lacks automated tests, leading to a system nobody fully comprehends.

#3about 3 minutes

How successful software outgrows its original purpose

Legacy software often becomes a victim of its own success, as its original design cannot support exponential growth or business pivots.

#4about 3 minutes

The critical problem of ownership and technical debt

A lack of clear ownership and the anti-pattern of putting technical debt in the product backlog prevents legacy systems from aligning with corporate strategy.

#5about 3 minutes

Questioning the default need for a REST API

A REST API is not a universal solution and can lead to awkward command implementations or a distributed monolith.

#6about 3 minutes

The myth that a new technology is always better

Rewriting software in a new technology often just replaces known problems with unknown ones without providing immediate business value.

#7about 4 minutes

Why you don't need to rewrite everything at once

Instead of a full rewrite, you can add new software for specific use cases and use routing to gradually replace the legacy system.

#8about 3 minutes

Moving beyond the default relational database

Embrace polyglot persistence by choosing the right data store for each use case and defining a single canonical source of truth.

#9about 4 minutes

The misconception that software migration is expensive

Migration costs are often inflated by unnecessary cleanup; focus first on making the existing code work in the new environment.

#10about 6 minutes

Why heavy abstraction is not needed in microservices

Small, self-contained systems can be rewritten easily, making extensive abstraction layers an unnecessary source of complexity.

#11about 2 minutes

How to introduce new patterns like event sourcing

New architectural patterns can be introduced incrementally for new features, building bridges to the legacy system without a full rewrite.

Related jobs
Jobs that call for the skills explored in this talk.
SabIna compys

SabIna compys
Vienna, Austria

Remote
20-100K
Intermediate
JavaScript
.NET
+1

Featured Partners

Related Articles

View all articles
CH
Chris Heilmann
All the videos of Halfstack London 2024!
Last month was Halfstack London, a conference about the web, JavaScript and half a dozen other things. We were there to deliver a talk, but also to record all the sessions and we're happy to share them with you. It took a bit as we had to wait for th...
All the videos of Halfstack London 2024!

From learning to earning

Jobs that call for the skills explored in this talk.