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.

Featured Partners

From learning to earning

Jobs that call for the skills explored in this talk.

Rust and GoLang

Rust and GoLang

NHe4a GmbH
Karlsruhe, Germany

Remote
55-65K
Intermediate
Senior
Go
Rust
Cloud Engineer (m/w/d)

Cloud Engineer (m/w/d)

fulfillmenttools
Köln, Germany

50-65K
Intermediate
TypeScript
Google Cloud Platform
Continuous Integration