Aug 21

Welcome to the new week!

Christmas came earlier this year. Remember the last webinar with Jeremy D. Miller about Simplifying Architecture with Wolverine?

We made it publicly available. You can watch it here:

Besides the architecture knowledge, it’s an excellent chance for you to check how webinars for paid subscribers look like. Check the complete list of the webinars we had so far.

One of the foundational things we wanted to show in the webinar is enabling focus on business behaviour. Focusing on the behaviour of our system is one of the foundations of my software design. That’s also a reason why I’m a big fan of modelling by events, CQRS, Vertical Slices and Feature Folders.

What could be more focused on the behaviour than Behaviour-Driven Design (BDD)? The answer is not so simple, as BDD definition is too often flattened.

I wrote my take on Behaviour-Driven Design and why I believe that's not (only) about tests.

Behaviour-Driven Design is more than tests

I feel that for developers, pushing BDD into the testing or domain-specific language corner is a way for an excuse. An excuse to outsource the responsibility of the behaviour to domain experts, business analysts and testers.

So developers could continue what they liked the most: typing on the keyboard without the need to express the business context.

Check also more in the intriguing talk made by Gojko Adzic

Gojko Adzic - You're Testing WHAT?

He explains how important it is to understand what we’re trying to test before thinking about how. I liked how he goes much further than the typical Code Coverage discussion that people are overfocused.

I like how Martin Fowler’s blog become a hub for other authors. I love his works, but now it has got to another level. I like how he’s giving a platform for diversed and high-quality voice of the community. Of course, it’s still biased by ThoughtWorks’ perspective, but who’s not biased? In the bias is also power, as we’re getting personal perspective. As long as we can understand and filter that through our view, we can get a much richer understanding than just flat articles trying to be objective at all costs.

Still, articles on Martin Fowler’s blog are quite often super thorough. For instance:

Sofia Tania, Stefania Stefansdottir - Surging cloud and managed services costs outpacing customer growth

It’s an excellent case study showing how to balance product growth and the cost of our services.

Too often, we decide to define our strategy based on our gut feeling and our past experience. The worst thing is if we don’t embrace that but show it as an educated decision and strategy that we should stick with. We can also cement our costs through the contracts, hiring strategy, and being unable to shift our strategy quickly. That usually ends up in drifting rather than quick iterations, which can mean a project failure.

Check also a short talk by Fred Moyer, where he shares his experience on SLOs budget management on the scale:

Fred Moyer - Techniques for SLOs and Error Budgets at Scale

If we want to reach the market, that’s a must-have. We won’t survive crossing the adoption chasm without that. All of that should be based on understanding the customer needs and shifting our strategies quickly to define SLO; that’s a good balance between customers’ expectations and our capabilities.

Product Management is one of the foundational aspects of building software products. Most of the failed projects I’ve seen so far failed not because of technical issues but because of not having a vision of the product. Product Manager is one of the hardest roles to fill. Such a person needs to be almost a renaissance man, understanding the business domain, customer needs, financial incentives, and technology behind products and knowing how to execute all of that.

Too often, I see this role being created so C-level people can push the dirty work on someone without giving enough authority to make product decisions. That’s a no-go, and it won’t ever work.

Still, I think that each of us should learn the aspects of building products and understand the challenges behind that. Even if we’re not planning to make the transition and won’t become product managers, our design will get much better.

See a few good recent materials on product design as inspiration:

Last week I mentioned recent OSS issues. Let me do a follow-up.

Moq author wrote a longer article explaining his motivations behind the issue he made:

Daniel Cazzulino - SponsorLink: feedback and moving forward

It’s a long wall of text to show that he still doesn’t understand that the community wasn’t mad because he wanted to have sustainable work on the library but because of how he did that and drove it. That’s also why understanding how to build a product is so essential. We open-source creators need to do a quick course on that.

There’s a new initiative called OpenTF; you can check their manifesto:

OpenTF - The OpenTF Manifesto

It’s a result of the HashiCorp licence change. This organisation wants to maintain the fork and maintain it. Interesting if some bigger cloud vendors like AWS, Microsoft or Google will join it. They’re the main reason why companies like HashiCorp, Elastic, Redis had to change their licensing not to be eaten by big corporations benefiting from their free work. My prediction is that they won’t and this initiative will be marginal, although I might be wrong, as a lot of companies made Terafform a critical part of their DevOps process.

William Gibson said:

The future is already here – it's just not evenly distributed.

It means that if we looked carefully, we would see the trends that will grow into commodities soon. That’s also a reason why I’m highlighting privacy and security issues. I wouldn’t like such things to become a commodity.

MIT Technology Review - China is escalating its war on kids’ screen time

ArsTechnica - An Iowa school district is using ChatGPT to decide which books to ban

Or are they already?

Check also other links!
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.