Voxxed Days in Amsterdam. Gave my presentation on Pipeline patterns and anti-patterns yesterday. Last slot so I was a bit tired. Did well enough though, I think 🙂

Eldredge yesterday and a Vidalia today.

#tieday #vdams26

Celebrating your milestones is almost as important as reaching them.

At a previous job, we would get "vouchers" for restaurant dinners with friends after hitting important milestones. Not a company-hosted team dinner; dinner with whoever you wanted to, wherever you felt like (within budget). The company would pay for it if you brought the receipt and the voucher.

---
Image by Harrison Chang via Unsplash

Togetherdays and #tieday in Falkenberg with the colleagues.

Trying out a Welsh knot today

All developers are familiar with (and mostly loathe) "boilerplate", but have you ever thought about where the word comes from and what code and boilers have in common?

In the late 1800s, boilers were made from thick, standardised, rolled steel sheets. These sheets were known as "boiler plates".

Around the same time, newspapers were all the rage. Printing presses produced thousands of pages per hour, and newspapers (literally?) flew off the presses.

--
Image: Sky via Unsplash

When embarking on a modernisation journey with your legacy system, it is important to have a plan for (roughly) what you want the system to look like when you're finished.

We call this an architectural vision, and as with all visions, it may not be what we end up with, but it is what we're currently striving towards.

We typically develop the vision using Domain-Driven Design. A context map of your business sets the overall architectural building blocks that your new system should consist of.

Posing with my sourdough for #tieday today.

Fridays aren't just #tiedays, it's also when I usually bake sourdough bread.

Sourdough baking takes a lot of time, but is also not very work-intensive, which means it pairs very well with my pomodoro breaks. Every 25 minutes, I go down to the kitchen and fold the dough. Then, after lunch, I shape it and put it in a proofing basket.

Without significant change of process and/or methodology, your new system will become your next legacy mess.

(Photo: Stacy via Unsplash)

The system you're replacing your ageing legacy with will be worse than what you have today.

This is because you are very likely to overcompensate for what you dislike in your current system.

Instead of a monolith, you might go overboard and have a hundred microservices,

You've heard about all these cool technologies that everyone else is using but haven't had the chance of trying, so you're using ALL of them.

(Image: "The magic roundabout", by Alby via Wikimedia Commons, CC BY-SA 2.0)

A lot of rewrites fail because they are cancelled before completion—and a half-finished rewrite is, in most cases, not usable.

No one is going to accept a complete feature freeze for one, two, or even ten years while you rewrite everything from scratch. This means that what you are starting to rewrite today will not be the same system you will be replacing once you finish the rewrite (if you finish it)—i.e. you are chasing a moving target.

(Photo by Sébastien Lavalaye via Unsplash )