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.

test

Milly
Vienna, Austria

Intermediate

test

Milly
Vienna, Austria

Intermediate

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.