Discover more from Architecture Weekly

Weekly Software Architecture resources to boost your knowledge and developer skills.

Over 3,000 subscribers

Architecture Weekly #130 - 5th June 2023

Oskar Dudycz

Jun 5, 2023

Welcome to the new week!

Last Monday, we had a webinar for paid subscribers of Architecture Weekly, discussing Postgres Superpowers in Practice.

You can watch it too and learn using the Fleet Management example of how Postgre can help to deliver faster business value. Almost two hours of practical knowledge and hands-on experience!

Real-world examples are always crucial as part of providing design. I wrote already longer on the risk of ignoring risks. Thinking about what can go wrong and finding potential remediations is essential. That can help us to find the unknowns and challenge the initial assumptions.

Andreas Öhlund and David Boike presented an intriguing technique of using anti-requirements. They wrote:

Anti-requirements are deceptively simple: you create some fake requirement concerning two attributes and present it to business stakeholders. “If the product has more than 20 characters in its name,” you say to them, “then its price must be at least $20.”
(…)

Without anti-requirements, teasing out these details can be tricky. Since business domain experts tend to think of this stuff as obvious, which makes them unlikely to volunteer this information. They’re generally surprised that developers don’t know it already. That makes it our job as developers and architects to dig for it.

Read more in:

Andreas Öhlund, David Boike - Using anti-requirements to find system boundaries

I like that idea, as I also observed in my projects that essential business knowledge is often not passed to us by the business. And it’s not that they want to or ignore it, just it’s so common for them that they assume it’s the same for us. Which too often is not.

Still, finding unknowns is just the homework that we should do. The real challenges are unknown unknowns. Our world is so complex that finding all the challenges is impossible. Based on our gut feeling is too big a risk and one of the reasons for failure.

I had the big pleasure of watching live the talk by Barry O'Reilly, where he explained his Residuality Thory. It’s a result of his scientific research and his experience as an architect. It’s based on the chaos theory but made actionable for us, mere humans.

Check his research and a bit older recording; we don’t have a lot of new thrilling ideas like that. It’s a must known about unknowns.

We should be careful not to overcomplicate our design and focus on delivering something good enough. I wrote about the Holy Graal syndrome, which in my opinion, is one of the fallacies and the reasons why we overcomplicate design. You don’t know it? Then read more in:

Oskar Dudycz - The Holy Graal syndrome

Getting back to business rules, do you know there’s a Business Rules Manifesto and a standard for business rules? Yes, it is. The page looks quite nineties, and the text looks a bit formal, but there are a lot of interesting and actionable points there. Check:

Business Rule Group - The Business Rules Manifesto

Getting back to the chaos, check talk by Holly Cummins, showing her lessons learned on running Microservices on the scale. All backed with personal experience on the staff that can go wrong, what we’ll have to deal with and how to survive the mayhem.

Holly Cummins - Cloud Chaos & Microservices Mayhem

Staying on the practical level, check the recording of Stefan Pölz webinar where he’s showing the mutation testing using C# as an example. Per Wikipedia:

Mutation testing (or mutation analysis or program mutation) is used to design new software tests and evaluate the quality of existing software tests. Mutation testing involves modifying a program in small ways.Each mutated version is called a mutant and tests detect and reject mutants by causing the behaviour of the original version to differ from the mutant. This is called killing the mutant. Test suites are measured by the percentage of mutants that they kill.

Together with property testing it’s one of the automated ways to discover what our code is missing. This is super important, as our tests usually can only verify what we predicted. Yes, even if we have 100% test coverage.

Test coverage is one of those metrics that can give a hint but not always show the whole picture. The same can happen in glorified DevOps DORA Metrics. Check what can go wrong if we’re too focused on measurements.

David Rant - How Not to Use the DORA Metrics to Measure DevOps Performance

On the DevOps part, see a nice walkthrough of the latest duel Service Mesh vs eBPF. So how to inject our common cross-cutting concerns into our system. As always, the stakes are complexity, performance and efficiency.

Jim Barton - Sidecars, eBPF and the Future of Service Mesh

Check also other links!

Cheers
Oskar

p.s. I invite you to join the paid version of Architecture Weekly. It already contains the exclusive Discord channel for subscribers (and my GitHub sponsors), monthly webinars, etc. It is a vibrant space for knowledge sharing. Don’t wait to be a part of it!

p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, and putting pressure on your local government or companies. You can also support Ukraine by donating, e.g. to the Ukraine humanitarian organisation, Ambulances for Ukraine or Red Cross.

Architecture

DevOps

Database

Java

.NET

Node.js

Turbo - Incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust – including Turbopack and Turborepo.

Management

Plane - Open-source, self-hosted project planning tool

Architecture Weekly