Forwarded this email? Subscribe here for more

Architecture Weekly #161 - 8th January 2024

Oskar Dudycz

Jan 8

READ IN APP

Welcome to the new week!

Not all issues are complex; some are "just" complicated. I noticed the funny thing: we too often feel more comfortable solving complex tasks than complicated ones.

We counterintuitively think: "Well, we just need to do research, then select a solution and solve it". Too often, that's our self-defence. We're tricking ourselves by postponing the issue. It's easier to justify our efforts in research than lag on known unknowns.

Let's say that we have two tasks to choose from. One is complex, and the other is complicated. They both have a similar business value. Shouldn't we choose the one with known unknowns?

I discussed that in my recent article and showed how to deal with complicated tasks systematically. I explained the real, dirty, complicated task I had to solve in Marten.

Oskar Dudycz - Not all issues are complex, some are complicated. Here's how to deal with them

I started it with a brief intro to the Cynefin framework. It’s not a technology but a decision-making framework. It helps categorise our issues and decide how to tackle them. Check also more from its author, Dave Snowden:

Dave Snowden - Complex Adaptive Systems

The other intriguing tool for designing, and modeling systems is TLA+:

TLA+ is a high-level language for modeling programs and systems--especially concurrent and distributed ones. It's based on the idea that the best way to describe things precisely is with simple mathematics. TLA+ and its tools are useful for eliminating fundamental design errors, which are hard to find and expensive to correct in code.

Leslie Lamport, its author, said a famous phrase:

A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.

And that’s what TLA+ is about a way to describe our systems and find the path for our program to work as expected. We focus on finding steps that have to happen for our system to succeed. Thanks to that, we’re reducing the noise of all the unexpected scenarios that may happen.

Read more in the latest version of his book, available for free:

Leslie Lamport - A Science of Concurrent Programs

Check also the talk by Scott Wlaschin, where he introduces Property-based Testing. It’s a much different level than TLA+, more on the techniques rather than strategies, but still, a useful technique for finding scenarios that we didn’t even know existed.

Scott Wlaschin - The lazy programmer's guide to writing thousands of tests

Speaking about the failures that one cannot easily predict. One of the weirdest failure scenarios happened for the Polish trains. Finally, we also have the full coverage in English to share with you.

The issue started in April 2022 when SPS company started servicing Polish Railway trains manufactured by their competitor, Newag. They could not start them and hired hackers to investigate the cause. Then, the same happened for other companies trying to service Newag trains. Newag responded with the accusation of trying to cheat and hack through the systems, blaming service companies and threatening to send that to the National Polish Security Department.

Hackers hired by SPS managed to unlock trains. Long story short, it appeared that the issue was DRM being installed by Newag. From 404 Media coverage:

The trains were designed to break if they sat idle for 21 days or if a GPS detected them at independent repair centers or competitors’ rail yards. Perhaps most interestingly, one of the analyzed trains had code in it that was supposed to artificially lock the train’s compressor on the seemingly arbitrary date of December 21; a NewAg train then actually had a compressor malfunction on December 21.