Last newsletter issue:

• London vs Chicago: The two ways of TDD 🔀: Whenever you get closer to TDD, you discover that two main approaches (schools) exist: they are called London School and Chicago School. But what are the differences? Let's see it together!

Read the full article and all the previous ones in our archive.

Video Podcast (ITA):

• The Weekly Pomodoro #8 - Some tips for wannabe/junior Developers trying to enter the IT job market

Watch episodes on YouTube here, or listen on Podcast using Spreaker or Spotify.

What if We do Ensemble Programming all the time? 🧑🏻‍💻👩🏽‍💻👨🏻‍💻👨🏼‍💻

Introduction

Hello, developers! 🚀

Today, the issue will focus on collaborative coding - we're exploring the practice of Ensemble Programming.

In this issue, we will look at the fascinating subject of Ensemble Programming, including its ideas, advantages, and possible impact on software development processes. Ensemble Programming has the potential to transform the way we develop software by encouraging collaboration and improving code quality.

So make sure to be ready to read this with an open mind while I tell you the potential benefits of adopting Ensemble Programming as a mainstream practice in the software business.

Let's dive in! 💻✨

From Mob to Ensemble

Some of you probably heard about Ensemble Programming under a different name: this is a synonym of Mob Programming.

Ensemble/Mob Programming is a collaborative approach to software development in which the Software Development team works together in real time on one task. In addition to software coding, the team collaborates to complete almost all tasks that a typical software development team would perform, such as defining stories, designing, testing, deploying software, and working with the customer. Almost all work is completed through "working meetings" or workshops, and everyone participating in the software development process, including our partners, is considered a team member.

Ensemble Programming is clearly connected to Pair Programming, an XP practice that you probably heard enough times from me: I love to say that this is an evolutionary step beyond the eXtreme Programming practice of Pair Programming, even more, “eXtreme”. When practicing Ensemble Programming we prioritize face-to-face and side-by-side communication, team alignment, cooperation, entire team engagement, continuous code review, and self-organizing teams.

So, some of you might wonder… why the name change?

As you can read here, the name Mob Programming was retrieved by Woody Zuill team when they set up this practice for the first time, and it felt like a good enough name for them. Then, Zuill started to advocate the practice, which became famous but… as mentioned here by Zuill himself:

Many people had been appalled by the term "mob" and hence didn't want to give it a try. Thinking of bullying or lynch mobs, the term is triggering trauma.

Therefore, in 2020, they decided to come up with a new name - and Ensemble Programming was the choice - a very good choice IMHO, that well expresses the intent of a “whole-team approach”.

Is this even possible?

I know what you all guys are thinking: “How can be sustainable to have the whole team work on a single task together? We need to parallelize, go faster, to produce more code! And the business will never buy into such an approach, btw!”.

I mean, if we said that Ensemble Programming is the “extreme” version of Pair Programming, it’s easy to expect that skepticism goes to his extreme also.

The problem, by the way, is always the same as when we discuss most Agile Practices: what do you think is “waste” in Software Development?

Waste in Software is a hard topic - but luckily in the latest years, the software world has collected some data, and, together with Lean and DevOps principles, we can have a better understanding of this compared to 10/20 years ago.

Waste in software is made of a lot of things, some of them unexpected:

• unplanned work - a category containing work such as bugs, defects, and any other unexpected problem that might show up

• features - the most unexpected type of waste; a research from Pendo shows that features usage mirrors the Pareto Principle: only 20% of features are always used; among the other 80%, 24% of features are never used; this is a HUGE waste

Some other type of waste exists, but those 2 are enough to show why Ensemble Programming is a great idea and improves the outcomes of the team.

First of all, how do we reduce unplanned work? The research in the book Accelerate shows that the percentage of unplanned work goes down from 27% for low-performing teams to 20% for high-performing teams. To achieve that, practices such as Continuous Integration and Trunk-Based Development have proved to be effective, according to the same research. In addition to this, working together works a lot better to improve quality code and share knowledge compared to Code Reviews, especially async once.

Therefore, the same benefits of pairing apply to mobbing and “goes extreme”: everyone works on everything, knows a lot, and continuously shares knowledge. No one can be a blocker for the team because “only he worked on such stuff”, or any similar example you can think of. We are still fundamental as individuals, by contributing to the work as a part of the team and not with individual contribution that we understand how to integrate when it’s done.

Ensemble Programming simplifies a lot of things: it’s a lot easier to apply Trunk-Based Development because we are all there and we can easily commit to master directly when we all agree on the solution; no review needed, no waiting time, the code goes straight to master and to a test environment.

But, what about features? Well… as we saw, building features shouldn’t be our priority - at all. Features are waste, we should work on them with an MVP and iterative approach as much as possible: build a small version of that feature, monitor its usage, and iteratively evolve it if the usage justifies it.

What we should optimize instead is lead time: the time that goes from idea/ticket creation to release in production. Optimizing that time will give us superpowers. As Lean and DevOps teach us, optimizing lead time means optimizing the flow of work - and limiting Work In Process (WIP) is a good way to achieve this. Again, we bring this to the extreme by applying Single-Piece Flow (WIP=1), working on one task at a time, as a whole team - therefore maximizing the flow of work.

Being able to go from idea to production requires also good design choices, of course - and working together we will maximize the quality of our design choices by having all our talent working on it and sharing a decision.

If you think about it, we typically see this happening naturally when a bug in production shows up: it happens quite often that the entire team groups around the problem while investigating the issue, looking together at logs, tests, etc to find the solution as soon as possible - and then, most of the times the fix happens also together, PR can be skipped because everyone already knows about it and code can go straight to production. So, when an emergency shows up, we naturally decide that working together is the fastest way to release a solution, even if it’s a stressful moment - why shouldn’t be a good idea to do this more often, or even all the time?

To finish my considerations, I also want to emphasize that Ensemble is very great not only from a technical/productivity but also from a cultural point of view: working together builds trust and psychological safety; it makes burnout less likely to happen, and, in general, makes it easier to introduce a junior in the team, and results in easier business success.

Especially in a remote world, where it’s harder to build a sense of teamwork and trust each other, we should favor sync work and Ensemble Programming: frequent, positive interactions as an ensemble make it easier to build trust and discover shared values.

Practical tips

Ok so - we have established that not only Ensemble Programming exists and makes a lot of sense for a lot of people - with proven data of its outcomes.

But I know how this works, and again I know what you guys are thinking - because I’ve been in your shows. This looks nice in theory, but impossible in practice.

So here I want to share some practical tips to start introducing Ensemble Programming in a team and see how it can work for you in your context - with some additional tips to set up it correctly and effectively from my experience.

Introduce Ensemble Programming to your team

Start with Learning

The first approach I can suggest is to start approaching learning as an ensemble; turn the learning time of the team into a team activity instead of an individual one: set book clubs and workshops, but also katas, coding challenges, and hackathons as whole team activities; the benefits of learning together will be visible, and the team will start to understand how working together gives better outcomes for most activities

Introduce Ensemble with bugs and small tasks

Typically, bugs and very small tasks are already handled in a special way than usual work; it’s very often that a hotfix can be merged in a special way than the usual PR process, for example - and the same usually applies to very small task such as one line changes that anyone in the team can do. Therefore, those are the best opportunities we have to introduce Ensemble: instead of investing time in aligning before letting one of the team do the work, just jump into doing it all together immediately.

Make a first try

Once you practiced the whole-team approach in small tasks a bunch of times, be ready to identify the best chance to apply it on a real task or bigger feature; ideally, it should be a piece of code where we already have a good agreement on the possible solution so that the conversation will be easier and the team can focus a bit more on the dynamics of working as an Ensemble. Don’t wait for the “ideal” task anyway - it will never come; just pick a task that at least a couple of the team have confidence in, and try it out!

Make Ensemble the default

Review the test session in a retrospective, collect what worked and what didn’t - and try to improve the setup to start making Ensemble Programming the default way of working for the team. It’s a one-way road, there is no going back once you see how amazing the result is - and you will never regret doing this.

Tips to improve Ensemble Programming sessions from my experience

Create an environment to make Ensemble work comfortable

People must be comfortable when working, and this is even more true when working in Ensemble; if you work in person, make sure there is a room dedicated to the Ensemble; there should be either a projector or a very big screen, more chairs than the people in the team - and ideally that kind of chairs that allow to easily look up, if you use a projector; ensure that is easy for everyone to quickly connect its own device (laptop, keyboard, mouse, etc) to ensure that everyone is feeling comfortable when driving the keyboard; if you do this remotely, make sure you use a tool for online meeting that allows for smart screen sharing, with the cameras always visible and the ability to draw on the screen for who is watching (it really helps conversations!!) - you can even use a collaboration tool to be able to work together on the code without committing, either on a local IDE or on a cloud environment, but be careful: committing often is a good practice, and being forced to commit something before changing the driven can be a helpful limitation.

Make up a rotation rule and stick to it very strictly

You have to set up some rules, and at least at the beginning when the team has little experience, it’s a good idea to strictly respect them. The most important rule is probably the one about rotation: there are multiple strategies to handle rotation when Pairing/Mobbing - if you are confident with TDD you can try ping-pong, where a member of the team writes a test, then immediately switch to another member that passes that test and write a new one, etc; or you can stick to a more standard chess-clock approach: just set up a timer, and switch the driver when the time is up. Make sure to let the team pick up their preferred strategy, the one that suits them the most: some teams prefer to stick to the timer very strictly, for example - when the time is up, you have to switch even unfinished work - while some others prefer to either rollback unfinished work or invest a couple more minutes to finish and commit.

Have a team break strategy, but allow for free solo breaks

The other most important rule when working in Ensemble, in my opinion, is the rule about breaks: it’s always important to have proper breaks during work, but it becomes fundamental when working in Ensemble because it requires some more energy. The best strategy here is to pick up a team break rule that matches with the rotation rule: for example, if you use ping-pong, you can still set up a timer and make a break when time is up. If you use a chess clock, instead, you can decide after how many timers there will be a break. Make the team set this up together, and make it explicit.

It’s always a good example to stick to some time and focus management strategy: the most famous is always the Pomodoro Technique: 25 minutes of work, 5 minutes of break (15 minutes every 4 Pomodoros). You can easily match this technique with a chess-clock strategy, which I think it’s the easiest setup to start: 25 minutes of work, 5 minutes of break, then another 25 minutes with a different driver - and so on - and if 25 minutes looks very little, you can consider some alternatives.

In addition to these team break rules, anyway, you should let people be free to take their own time: someone might have a bad day or need some time for any reason. Make an explicit rule about allowing people to take a break at any time, especially when they are not the driver, without even asking - and make sure that people are aware of this rule and feel safe to use it.

Share a netiquette and make it transparent

While I decided that 2 rules deserved their spot, is a good idea in general to write down the rule set of the Ensemble sessions in a shared netiquette: this is typically a great first task to work on as an Ensemble.

In the netiquette, make sure that everything is explicit - keep it simple, but clear, so that no understanding shows up. Of course, be always ready to improve it if any negative feedback shows up from experience - and if you do this as a team, it will be easier for people to “disagree and commit” while fixing and improving.

The purpose of the rules is not just to avoid discussion - is to make sure that the team commits to a shared understanding (which is why they should be decided by the team and not imposed) and they are responsible for themselves. They can set it up as they want, as soon as it works and produces a good outcome, and can keep improving it over time in autonomy.

Involve non-dev people

Whenever the team needs non-developer members of the team to progress with the work, involve them in the Ensemble. Typically, it works well to involve UX designers while finalizing the frontend development, for example - or involving a domain expert while building a new feature, spike, or experiment.

Involve the most people possible the more time possible - it can be hard work to let people outside developers the value of this and make sure to help them on this, but it’s game-changing.

For example, it typically is a great idea to write Acceptance tests together with domain experts and stakeholders - but putting them in front of code is very hard for them, so using a higher level language, even English, with explicit examples can work well and allow you to convert that in code.

An easier example is related to UX designers, that can typically be involved in the Ensemble while developing a Design System because 100% of the code has an impact on what they design.

Find a good balance between doing this in front of code (when it’s really necessary) or in a physical/digital workshop or anything else, but make sure that you spend some effort in involving also non-developers, even customers, in the Ensemble continuously.

Monitor the right metrics

This is true in any Software Development Team, but I want to discuss this to answer the question: “Can I monitor if it’s working?” - IMHO, the answer is: “Yes, if you monitor the good stuff”.

DORA metrics are still the best choice we have today, and you should expect to see them improve when starting work as an Ensemble. In addition to that, is always a good idea to set an Employee NPS every week or two to let people anonymously express how they feel and therefore check if there is improved feedback from the team. And also talk about it in the retrospectives and 1to1 meetings - conversations always help!

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

📚 Books

• Software Teaming: A Mob Programming, Whole-Team Approach - the reference book on the practice, by Woody Zuill itself.

• Code With the Wisdom of the Crowd: Get Better Together With Mob Programming - See how to avoid the most common pitfalls that teams make when first starting out.

• Remote Mob Programming: At home, but not alone. - Remote Mob Programming combines two ways of working: Mob Programming and working as a distributed team.

📩 Newsletter issues

• Ensemble programming is more efficient

• Team Lessons Found Only in Ensemble (Mob) Programming

• How High-Performing Teams Review Code

📄 Blog posts

• Mob Programming - an Interview with Woody Zuill

• 8 reasons why we do ensemble programming

• How to build a strong culture with ensemble programming

🎙️ Podcasts

• The Mob Mentality Show

• Mob Programming with The Mob Programming Team

• Woody Zuill on Mob Programming and Influencing Change

🖥️ Videos

• A day of Mob Programming (Woody Zuill)

• AVOID These Mob Programming / Ensemble Mistakes (Emily Bache)

💡Master Agile Methodologies with Learn Agile Practices

Are you a Software Developer eager to accelerate your growth and become a senior developer? Discover what Learn Agile Practices offers to help you on our About page.

Thanks again for being a part of our journey! 🙏

📣 Remember: as a subscriber to this newsletter, you have a dedicated discount for any of our digital products/services. You can find it in your subscription email confirmation, or just hit me via email or social media and I will send it again! 😉

Last newsletter issue:

• eXtreme Programming for Remote Teams: XP is the parent of a lot of best practices known today: when it comes to remote teams, anyway, some of its values, principles, and practices seem to be incompatible... but is this the truth?

Read the full article and all the previous ones in our archive.

Video Podcast (ITA):

• The Weekly Pomodoro #7 - How to approach learning TDD effectively

Watch episodes on YouTube here, or listen on Podcast using Spreaker or Spotify.

London vs Chicago: The two ways of TDD 🔀

Introduction

Hello, developers! 🚀

We go back to talk about Test-Driven Development (TDD) today, with a little twist—we're exploring the two main different approaches of the two iconic TDD schools: London and Chicago.

Each TDD school brings its unique flavor to the table, offering a different perspective on how to approach software testing and development with TDD. In this article, we'll describe the two approaches and compare them.

In an imaginary travel from America to England, let’s see what London and Chicago Schools have to offer for TDD practitioners.

Let's dive in! 💻✨

A Tale of Two Cities

First of all, I want to make sure everyone knows what I’m referring to when I mention London or Chicago schools.

When we first meet TDD, we typically first see it via the Chicago School: a.k.a. Detroit School, this school follows an Inside-Out approach; this provides a more exploratory, state-based way to solve the problem by starting from the inside of the application (from the core domain models, for example) and works out towards the APIs.

Most of the time, this is the typical approach I see when it comes to tutorials and examples online, especially those for beginners - probably just because it’s easier to start making examples on small pieces of code and then putting them together afterward.

Usually, the pros and cons of the Chicago School are considered to be:

• Pros

  • since typically the collaborators we need already exist, It’s easier to keep tests decouples from the implementation, and the use of Test Doubles is minimized

  • It’s easier to have a higher cohesion because we start with very specific tests to more generalized ones - and this promotes high cohesion

• Cons

  • It’s harder to respect the YAGNI principle and avoid over-engineered solutions - while TDD still reduces these risks, going from the inside to the outside can still bring to some of these situations because you look at the higher level later

The London School, on the other hand, follows the opposite Outside-In approach; this provides a formal, behavior-based way to solve the problem by starting from the outside of the application (from the APIs or controllers, for example) and working its way through the lower layers.

This school is called in multiple ways (Mockist TDD, or the most famous ATDD, which stands for Acceptance Tests Driven Development) and is the approach that you typically face after you start being fluent with TDD in general.

Usually, the pros and cons of the London School are considered to be:

• Pros

  • It’s an approach more focused on the behavior of the application and the interface used by the user - like in Contract-First API development, you start by thinking about how the client will interact with your code, and then move more on the inside later

  • CQS (Command-Query Separation principles) is easier to implement: CQS is an approach that promotes classes that have only methods that either read data or change data, which improves readability and maintainability

• Cons

  • Higher risk of more fragile tests: starting from the outside will require using mocks to replace the collaborators we need and still don’t exist; we need to be careful and use best practices here to ensure that we don’t tight too much to the implementation, otherwise our tests will break at every change; one example? Favor manual written Fakes and Spies instead of Stub and Mocks set up with mock libraries

  • Refactoring might be harder: for the same reason, if we tighten too much our tests to the implementation, every refactoring will also require changing tests - and this is just wrong since refactoring should be done by never breaking our tests; be careful with those mocks!

The best of two Worlds

The two approaches both have pros and cons, and it’s important to learn them and then make use of the good side of both. But let’s make this clear: the point is not about choosing one of the two. The point is to understand them both to build an integrated adoption of these two schools.

For example, in a standard process of building a new feature that the client will use via API, I typically start the work following London Outside-In School: this way, I start focusing on the way the client will make the request, and which response he expects, to start building first from the interface he will use. Similar to the Contract-First API approach, this is a good way to ensure that the way you talk with the client is not coupled to the implementation - because the implementation still doesn’t exist. It’s a great fit, because the controller in a good architecture will typically only handle the request validation, and then talk to the Service that will implement the behavior. And if we follow CQS, creating a fake/spy for our queries/command handlers is the best way to use Test Doubles.

Chicago School is typically more useful to me when it comes to the Service because this is where the behavior will happen. First of all, sometimes the behavior is complex and the problem is hard to understand - and this is where the power of TDD comes out the most. Second of all, here we will probably have some collaborators because we might need to change the state of our application (write on a cache, file, database, or whatever - or change a runtime value) or interact with an external API.

When the need for those collaborators is clear from the start, I typically start by building those, focusing on how they specifically work (if I don’t know yet), and then putting the behavior together. I will then decide if it’s best to have a Double or use the concrete implementation in the test of the Service. When the behavior is less clear, instead, I have a hybrid approach: I typically start by implementing it all in the service in a “Chicago way” like it’s the lowest piece of the puzzle and then extract the pieces that make sense to isolate. The same decision about keeping the real concrete of the new collaborator extracted or replacing it with a Double in the test will need to happen here.

Craft your way to TDD

Finally, I want to share with you some tips from my experience about how to start practicing, and then practicing and one day even mastering, TDD - and which of the two Schools to favor.

As you can imagine, the answer is: “It depends”. The target should be to understand them both, and like I did in the example of the previous section, understand how to put them in your context and mix them to achieve the best outcomes possible.

My first tip is for beginners: at first, you should strictly follow the cycle, the law, and the best practices as they are described in TDD books, especially the original one from Kent Beck. The reason is that when we are learning something, having rules to respect is easier - and then when they become a habit and you already see some of their benefits, it’s easier to learn even more of why that works and how to become even better.

The second tip is for people that already started to become fluent with TDD at least on Katas and Side Projects: make the leap and start using TDD in real features. If you work on a legacy system, start using TDD with new code, where it doesn’t have to necessarily impact the old one. Then, move to bigger features, discover how to add tests to non-tested code properly (a bit of Refactoring is needed here), and progressively raise the bar. And then, as soon as you have the chance to work on a greenfield project, develop the system from scratch in TDD.

The third tip is for a bit more experienced developers who have worked in TDD for some years: if you never did it, consider re-reading the book from Kent Beck - I’ve done it a couple of times more after the first one, and especially the 2nd part about TDD patterns is always a discovery of new tips that you can more easily understand when you have some experience - that book is not just a tool to start, but it can also help you master TDD. In the alternative, there are some other great books that talks about TDD - check the “Go Deeper” section for my tips - and they can always give you an alternative point of view that helps your growth.

And then, finally, I have a bonus tip for skeptics: try to give TDD a chance. A real one! Trying to do TDD in real production code without practicing before - or practicing only once - it’s not a real, proper chance. I understand that some might be reluctant to the approach, but there is evidence out there proving that TDD (and some other practices such as CI, Trunk-Based, etc) produce better outcomes. My suggestion is to give yourself at least 8 hours of practicing: doesn’t matter if it’s continuous time, or splitter in 30 minutes per day (if you practice, make sure you do at least one Pomodoro) - but I think that 8 hours of practicing, while reading books or other learning content when we face struggles, is the minimum time required to be sure you started understanding something concretely. And even if you still don’t like TDD at that point, I’m sure that at least it will give you something to think about.

In the end, the key is to embrace the essence of TDD: iterative development, continuous testing, and a relentless focus on quality.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

📚 Books

• Test-Driven Development: by Example - Quite simply, test-driven development is meant to eliminate fear in application development. Kent Beck teaches programmers by example, so they can painlessly and dramatically increase the quality of their work.

• Growing Object-Oriented Software, Guided by Tests - A practical guide to TDD that takes you beyond the basic concepts. Drawing on a decade of experience building real-world systems, two TDD pioneers show how to let tests guide your development and grow software that is coherent, reliable, and maintainable.

• Agile Technical Practices Distilled - The book that changed my career: it explores the fundamental practices of Agile working, including test-driven development (TDD), refactoring, pair programming, and continuous integration.

• Accelerate - Readers will discover how to measure the performance of their teams, and what capabilities they should invest in to drive higher performance. Spoiler: one of those is TDD!

📩 Newsletter issues

• Canon TDD (by Kent Beck itself!)

• Everything I know about TDD

• The Basics of Test-Driven Development with a Focus on Data Structures

📄 Blog posts

• 30 Days of TDD: Day One – What is TDD and Why Should I Use It?

• How to get started with Test-Driven Development

• Getting Stuck While Doing TDD. Part 1: Example

🎙️ Podcasts

• TDD for today (ThoughtWorks)

• TDD: Don’t be afraid of Test-Driven Development - Chris May

• Test Driven Development (TDD) in Angular

🖥️ Videos

• Test Driven Development Tutorial For Beginners

• Test Driven Development TDD Crash Course 2022 | What is TDD in Java | Learn Java TDD - English

• Introduction to Test-Driven Development (TDD) with TypeScript | 2021

💡Master Agile Methodologies with Learn Agile Practices

Are you a Software Developer eager to accelerate your growth and become a senior developer? Discover what Learn Agile Practices offers to help you on our About page.

Thanks again for being a part of our journey! 🙏

📣 Remember: as a subscriber to this newsletter, you have a dedicated discount for any of our digital products/services. You can find it in your subscription email confirmation, or just hit me via email or social media and I will send it again! 😉

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome back to Learn Agile Practices, the home of continuous improvement and learning for Software Developers.

📌 In case you missed it

In the last issue last week, I wrote about Async stand-Ups: is it really a good idea to go async with such practice? I don’t believe it is: if you haven’t yet, you can read my controversial opinion in our archive.

And for those of you who speak Italian, this is what you can find on my video podcast from last week:

• The Weekly Pomodoro #6 - You can apply CQRS without Event Sourcing… and you should!

• Dev Debate #2 - Accelerate, Continuous Integration and burnout w/ Ruggero Visintin

Watch episodes on YouTube here, or listen on Podcast using Spreaker or Spotify.

🔥 Available for mentoring and coaching

I’m always available for some mentoring and coaching to other software developers! Feel free to reach me: we will know each other and discuss what path can be best for you, from a free monthly mentoring path to a more frequent one or a 1-to-1 coaching service specifically on your needs!

👉 Feel free to reply to this email or reach me on any social media: all the details on my website.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

eXtreme Programming for Remote teams

Introduction

Hello, developers! 🚀

I’m a big advocate of eXtreme Programming, as most of you already know: since the first time I read “eXtreme Programming: Explained”, this methodology has become part of my daily job as a Software Developer and it’s the core of what I typically bring as suggestion when I’m technical coaching.

Then, remote work became a habit and it seems that the direction where this type of work is going is diverging from the values and principles of XP itself; most people think that XP (and Agile) practices are not compatible with remote - but is this actually the truth?

Let’s dive into the issue and discover what I think about this!

💡 This is the "sequel" of an old issue: I will expand and explore the topic here, focusing more on XP, but if you want, you can read the first part 👉 here.

Values and principles are universal

XP was my first step into the Agile world, and it was enlightening. I always tell this story: when I first heard about a methodology called “eXtreme Programming”, I immediately thought it was related to coding for hours overnight like in some movies - the word extreme in the name is pretty misunderstandable, to be honest.

Then I read the book and the reason for the name became more clear:

The idea is simple, yet revolutionary: if a thing works well, let’s do it more often. Let’s do it always! Why not?

From a high-level perspective, XP is something everyone can easily agree on: the 5 values (communication, simplicity, feedback, courage, respect) are something that most developers themselves can think of as ideal values for their work. We all want effective communication, simplifying our work, and respect - and we can easily discover the importance of feedback and courage.

Similarly, principles are still enough high-level that most people will easily agree: if you ever meet someone who doesn’t agree with principles such as humanity, mutual benefit, improvement, diversity, etc… - well, run away as fast as you can!

It’s great that XP is based on such universal concepts, of course: this can help in setting up a conversation about it because we can easily start with a shared agreement on them. On the other side, this is just too high level: making values explicit is important because, without values, practices quickly become rote, activities performed for their own sake but lacking any purpose or direction.

Practices, on the other hand, are evidence of values. Values are expressed at such a high level that I could do just about anything in the name of value. Practices are clear.

Principles bridge the gap between values and practices. Principles are domain-specific guidelines for life, that starting from values can lead to practices that respect all of them.

By far, IMHO, everything related to XP Values and Principles is “location independent” - meaning that remote work has no impact on their application: we want our organization to be respectful, communicate well, favor diversity, etc - no matter if we are remote or not.

XP practices for remote teams

Practices are the kind of things you will see XP teams doing daily.

Applying a practice is a choice: XP offers a collection of practices that work and work even better together, and they have been used before, and those are the practices listed in Kent Beck’s book. Practices only make sense if related to principles, otherwise, they become rote; pairing just to make your boss happy is frustrating, but if you recognize its values in communication, feedback, simplicity, courage, and respect it makes a lot of sense.

But remember that practices are situation-dependent: if the situation changes, you will choose different practices to meet those conditions.

Values don't change, and principles can be used to figure out something new.

Today, I want to focus on some of the practices suggested by XP: I will focus on the most important (in my opinion, of course) but also on the one that can more easily be seen as harder when remote, to share my thoughts about the impact of remote work on them.

Sit Together

Let’s start directly with one of the easiest practices to put into discussion when working remotely: “Sit Together” means that people should work in a shared space big enough for the whole team. Of course, this is just not possible if we are working remotely… but the reality is that we don’t have to interpret this practice in such a concrete way.

Kent Beck itself, in the 2nd edition of the book, added some additional notes related to remote work, and states that multisite teams can do XP: the point is that practices are just predictions - here, for example, the prediction is that the more face time you have, the more human and productive the project will be.

But today, technology can easily help and make teamwork remote: we can easily set up virtual rooms, with both video and audio and also the chance to share screens and documents - and we can also move some of that conversation async (not all, not even most, only some!).

Of course, if you have problems related to teamwork think about ways to sit together, even if it requires traveling.

Pair Programming

My dear Pair Programming! It always comes back in my writings, at some point. I’m referring to Pairing because it is explicitly quoted in the book, but this point can also be applied to Ensemble Programming (aka Mob Programming, which we can simplify to “pairing with the whole team” - and what is Mob if not the “extreme” version of Pairing? 😉

Pair Programming is already hard enough to make a habit when working in the same space for a lot of developers - which is sad, in my opinion - so it is no surprise that even more people think it’s harder when working remotely.

I think that, if we have a good enough setup, it’s the same: we can easily share a screen today, or use a collaborative tool that allows multiple people to change the code together; we can easily have a webcam always on so that we can always see each other and talk to each other; we can easily share an online board like Miro for some brainstorming or sharing ideas; technology is growing and evolving daily, and it will help always more.

There is only one thing about Pair/Ensemble Programming that is still important when in person, but it becomes fundamental when remote: taking breaks! When working remotely, we have the additional fatigue coming from all the conversation happening on a screen, typically also with headsets - so having regular breaks is not just a good idea, it’s required to keep the work healthy.

Code and Tests

This practice is not much known as the others, but I think it’s important to share some thoughts about how we can adapt XP practices keeping values and principles in mind: “Code and Tests” suggests that code and test should be the only piece of work maintained from the team; any other document should be generated from them, and we should rely on social mechanisms to keep alive the important history of the project.

This practice is a companion for the Agile principle of “working software over comprehensive documentation” - we should be able to make the team only work on code and tests, and any other artifact such as documentation should be generated from them.

First of all, this description is ideal and it’s very hard that we can do that, no matter where the members of the team work from. But still, it should be our target. That’s why is a good idea to generate a Swagger doc from annotations in the code, for example.

The main issue with this practice when going remote is that “social mechanisms” are different, and sharing information is harder and less natural; on one side, we can fight this by working in sync - I know that the industry goes the opposite way, but remember: async is good only for some things, not all, not even most of things. On the other side, we need to invest some time in writing down information and making it accessible - but be careful, this doesn’t necessarily mean writing down documentation.

Do we need to share how to set up the project? Let’s create a script to automate that - it will make it easier to onboard new people, and they will still be able to read the script code to discover what it does.

We need to document decisions? Implement ADRs in a dedicated repository using MD files - and you could even build automation to publish them and make them searchable.

This kind of approach has a much higher ROI compared to simple documentation.

Continuous Integration

Continuous Integration means that our code has to go into the main branch at least once per day. It is a synonym of Trunk-Based Development, and it is the opposite of Feature Branches. It is also not the best friend of Async Pull Request, but they can live together if the team is responsible.

I know that Feature Branches are something that also teams working in the same place do most of time - for some reason, this way of working has become so popular - but I feel that it’s even more used by remote teams. In general, remote teams tend to accept isolation of work for individuals for a long time - this helps the work-life balance, they say. It’s just not true.

Anyway, there is no specific solution related to remote here: my suggestion is just to try to force yourself to have branches that live 24 hours at most, and see what happens - you will discover a powerful technique.

Additional point: since your team will have a good number of reviews if you start having 1-day branches, people will collaborate more in a natural way - and you can even consider a different approach to PRs such as “Skip/Ship/Show”.

Real Customer Involvement

The last practice I want to talk about is about involving customers in our daily work: we should make people whose lives and businesses are affected by your system part of the team. Visionary customers can be part of quarterly or weekly planning.

You will get different results with real customers involved. When you act trustworthy and have nothing to hide, you are more productive. This is already hard and rare enough in general, and it can appear harder to achieve in a remote work context.

I believe that if your company has a culture of involving the customers, you will be able to do it independently from being remote or not. Again, if the customers are tech-savvy enough, technology can easily help nowadays - and if customers are not that tech-savvy to do it on their own, you can invest some workforce in helping them share their thoughts in other ways.

Conclusions

I think we can safely say that we can try to implement eXtreme Programming even if we are working remotely; the most important thing is that we need to be sure to respect values and principles, that are the foundation of a good, healthy company and tech culture.

Once we are aligned on those, we can easily pick the practices that we all agree on, and start from there; then, we can respond to our issues by testing other practices or by creating our own.

Embrace XP, you will never regret it!

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

📚 Books

• Extreme Programming Explained: Embrace Change - this is just THE book on the topic - make sure to read it before starting your XP journey. It’s clear, simple to read, and gives a lot of inspiration about our work in general.

• Extreme Programming: Installed - The book consists of a connected collection of essays, presented in the order the practices would be implemented during a project. Ideal as both a start-to-finish tutorial and quick reference, the book demonstrates exactly how XP can promote better communication, quality, control, and predictability.

• Agile Technical Practices Distilled - This book uses the term Agile as a wide umbrella and covers Agile principles and practices, as well as most methodologies associated with it - XP included.

📩 Newsletter issues

• Scaling Extreme Programming: Dependencies

• Appreciating Your Way to XP

• The Surprising Truth About XP and Agile in Remote Work Environments

📄 Blog posts

• XP in remote times

• 5 XP practices that will make your remote team more effective

• Making Extreme Programming Work for Remote Teams

🎙️ Podcasts

• Practising XP (Extreme Programming)

🖥️ Videos

• How does an XP team operate?

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome back to Learn Agile Practices, the home of continuous improvement and learning for Software Developers.

📌 In case you missed it

In the last issue last week, I shared my thoughts about the CQRS pattern: I highlighted the pros and cons of that pattern and shared why I think it deserved more spotlights, not necessarily paired with some other pattern like Event Sourcing. If you haven’t yet, you can read it in our archive.

And for those of you who speak Italian, this is what you can find on my video podcast from last week:

• The Weekly Pomodoro #5 - Accelerate and the importance of Agile practices

Watch episodes on YouTube here, or listen on Podcast using Spreaker or Spotify.

🔥 Available for mentoring and coaching

I’m always available for some mentoring and coaching to other software developers! Feel free to reach me: we will know each other and discuss what path can be best for you, from a free monthly mentoring path to a more frequent one or a 1-to-1 coaching service specifically on your needs!

👉 Feel free to reply to this email or reach me on any social media: all the details on my website.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

Are we sure async Daily Stand-ups are a good idea? 🤔

Introduction

Hello, developers! 🚀

In this issue, my battle against going async for everything when working remotely takes another step 😃: I will talk to you about Daily Stand-up meetings!

This practice is one of the most used (and abused) among all the Agile practices, and it has been misinterpreted and misused for a lot of years (the usual example is that it becomes an update meeting) - and now that working remotely has become very common, a lot of tools that implement an “async” stand-up are used by a lot of teams, adding another misuse of the practice.

Today, I will try to describe what purpose such meetings are supposed to achieve, and why they are important, going back to what I think is one of the most underestimated objectives of Agile: collaboration!

Since I came up with the idea of this post from this post on LinkedIn, and some comments below, you should have a look at it before reading this - I will still make a short intro through it anyway.

The real purpose of a Daily Stand-up meeting

The Daily Stand-up Meeting is one of the most used among all the Agile practices - and also one of the most abused, misused, and misunderstood.

Let’s start with a generic definition: the daily Stand-up is the practice of grouping the team 15 minutes per day in a meeting where everyone takes the word for a minute, typically responding to 3 questions:

1. What did I do yesterday?

2. What will I do today?

3. Do I have any blocker or issue, or do I need any sort of help?

We can sum up the goals of this practice into two things: status updates (question 1) & planning the day (questions 2 and 3): the purpose is to sum up what each of us did yesterday, and then plan the new day of work together.

Over the years, I’ve seen and heard of multiple common anti-patterns in daily stand-up implementation, doesn’t matter if in person or remotely:

• too much focus on the status update: people simply recap what they did yesterday and what they expect to do today, mainly talking to the PM to let him know and eventually discuss blockers

• too much focus on individual work: people are only focused on their moment of speaking, but have no interest in listening to the other members of the team because the work is intended to be individual

• too much focus on the timing: respecting the time frame (typically 15 minutes) becomes more important than achieving the goal of the meeting

• putting it in the middle of the day: as in the LinkedIn post, since people tend to get tired of stand-ups when they are only used as a status update, they start finding solutions to make it less tedious for the team; moving it in the middle of the day typically helps to achieve this, because people thinks “I already hate enough having a status update every day, at least do not force me to arrive early in the morning and talk as a first thing in the day” - understandable, since the meeting is completely non-sense when only focused on status updates.

• going async: a different response that remote teams have to feel tired of status update stand-ups is to make them async; using some online tool, people can send their update at any time and in multiple formats (some use text messages, some use short videos, etc..) without the need to enter a sync meeting; that would be a good idea if the goal of the standup was the status update - but as I already said, that is not the main goal, is just a small part of it.

Those anti-patterns are typically the consequences of a non-ideal approach to Software Development: teams that don’t approach Software Development as a team effort. What most team still does today is to work as individual contributors on a shared codebase: each team member gets a ticket assigned by the PM (doesn’t matter if the P stands for Project or Product here) and works on that for the time required (at least some days, typically). Once they are done, they open a PR, discuss it with others (typically async via GitHub comments), and then merge it.

What Agile, XP, and Lean suggest, each in their way, is a different approach: Software Development works best when done as a team effort work. People should work more closely together, integrating their code more often, and in general, collaborate continuously during the day to ensure the Software achieves business results.

With this in mind, it’s easier to understand what Daily Stand-up should really be about: the main goal is to plan the day.

Async is good for status updates, not for planning and collaboration

If you accept that the goal of the Daily Stand-up is to plan the day and see things from the perspective of a team that closely collaborates to achieve business success, it makes a lot of sense to state that:

The Daily Stand-up should happen in sync and at the beginning of the day.

First of all, having the Daily Stand-up at the beginning of the day is a perfect match with the target of planning the day: it becomes the tool to trigger the “work is starting” message to our brain; thinking about where you left yesterday, and then planning what you need to do today to progress is ideal as first thing in the day.

This meeting is the practice suggested to also set up the collaboration we need among the team for today: for example, this is typically the moment when Agile teams set up pairing or mobbing sessions for the day, or ask for a sync PR review on the latest changes, or set up some additional refinement or customer feedback moment, for example.

On the other hand, there is the need for synchronicity: async communication is a better choice in some cases; for example to collect ideas, share status updates, or any kind of data in general, especially when a wide audience is interested in reading them - but, sync communication is far more effective than async when we need to brainstorm solutions, ideas, work together and collaborate. And this should be what Software Development teams do continuously every day: work together and collaborate.

When a team works mostly async, in the configuration of multiple individual contributors working alone most of the time and then putting the code together when done, typically after days of isolated work on a branch, then I’m sure that the standup is probably just a status update for you, and going async can probably improve your day in the immediate. But I have to say that I think this is not an ideal way of working in software: we can achieve more freedom and flexibility differently and still collaborate a lot during the day.

If you are more open to considering working together, I strongly suggest that you focus on improving your Daily Stand-ups by focusing mostly on the planning part: spend a few words on what you did yesterday just to sum up and start the talking, but move fast to planning today. To improve even more, start asking someone to pair with you, at least when you are doing something hard or very important - this will not only reduce the time for PR reviews but also make the Stand-up quicker.

Bonus point: once you move to collaboration and pair or mob most of your time, you might even not need the Daily Stand-up or reduce it to 5 minutes - because the team will be much more aligned and working together, therefore the need to orchestrate will be minimal.

What if you really want to go async?

The best tip I can give you is to do whatever it takes to focus on planning today way more than updating on what you did yesterday. If I had to run an async stand-up, I would suggest the following things:

1. Use a template: with a template we can make it faster to write (or say, if it’s audio/video) the message, but also easier to read/listen to it for the others; should take no more than 30 seconds to read/listen the message to the others, so that going through all the messages takes around 5 minutes and the cognitive load remains low.

2. Make it video: I would favor a video format, with a webcam + shared video on the board highlighting the tasks while are discussed; video format favors communication because spoken + face works far better than written one and makes it also easy and fast to say if we need some support.

3. Define an ideal time limit: I think it would still be important to have it at the beginning of the day; it can be a problem if you are totally async, but generally speaking the working hours might be different but are similar; for example, asking to submit our daily message before 10 or 11 am looks reasonable to me.

4. Define how to set up collaboration for the day: I would still try to force this stand-up moment to focus on setting up the day way more than being a mere status update, so I would decide a way to ask for some collaboration/help.

An example to favor collaboration after an async standup would be to have a tool where the person in need of help would start a conversation (it can be something like Stackoverflow for teams or simply Slack); the conversation starts in an async way, but everyone should be ready to go in a sync meeting as soon as needed, immediately if people are available, or scheduling a meet asap; the expectation would be that the person asking for support open the conversation leaving all the info in the first message, mixing text, video, and screenshots - as I said, collecting ideas and sharing info in async is a good idea, just ensure that people are happy and ready to move to sync communication as soon as required.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

📚 Books

• Extreme Programming Explained: Embrace Change: this book doesn’t talk about stand-ups in general - but we can use it to reflect: are we respecting the values and principles of XP with our current stand-up? If yes, keep improving - if not, either fix it or remove it.

• The Async-First Playbook: Remote Collaboration Techniques for Agile Software Teams: I’m not a fan of going async, as you know; “async first” make some sense, “only async” makes no sense at all, IMHO; but this book comes from Thoughtworks so it’s worth reading it and taking inspiration from it if you work remotely.

📩 Newsletter issues

• How to stop your standups from turning into status updates.

• A Quick and Easy Slack Hack to Augment My Team’s Daily Standup

• Choosing Wisely: When to Go Sync ⏳ and When to Go Async ⏰ in Software

📄 Blog posts

• Asynchronous Daily Standups: Pros, Cons & Best Practices

• Don't Let Async Standup Kill Team Effectiveness

• Asynchronous Daily Standups (How They Work for Remote Teams)

🎙️ Podcasts

• Is it time to ditch the remote daily stand-up?

• BEP 314 – Project Management 5: Scrum Stand-up Meetings

🖥️ Videos

• Daily Standup: You're Doing It Wrong! (What Does A Perfect DAILY SCRUM Look Like)

• How to Run The Perfect Asynchronous Daily Scrum (compatible with SCRUM??)

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome back to Learn Agile Practices, the home of continuous improvement and learning for Software Developers.

📌 In case you missed it

In the last 2 weeks, in this newsletter, we discussed Continuous Integration and Trunk-Based Development: there you can read the 2-parts article that includes a quick introduction to the 2 topics, some coding patterns that you can use to hide unfinished work, and some real-world examples from my experience. If you haven’t yet, you can read it in our archive.

And for those of you who speak Italian, I also discussed the same topic last week on my video podcast:

• The Weekly Pomodoro #4 - Trunk-Based Development coding patterns

Watch episodes on YouTube here, or listen on Podcast using Spreaker or Spotify.

🔥 Available for mentoring and coaching

I’m always available for some mentoring and coaching to other software developers! Feel free to reach me: we will know each other and discuss what path can be best for you, from a free monthly mentoring path to a more frequent one or a 1-to-1 coaching service specifically on your needs!

👉 Feel free to reply to this email or reach me on any social media: all the details on my website.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

CQRS pattern: advantages of Command and Queries

Introduction

Hello, developers! 🚀

Today’s topic is one of those that made me desire to stand up for a discussion when I heard about it: the Command-Query Responsibility Segregation pattern (CQRS) is very powerful and useful but it’s usually only discussed together with Event Sourcing (ES) and this is a pity.

I think CQRS deserves its autonomous role in Software Development and should be discussed more because it is a powerful technique to organize our software and keep it maintainable.

This is what I want to do with this issue: describe what the CQRS pattern is about, with some practical examples and usages, and especially highlighting its advantages on a business application and why it makes total sense to apply it on its own, no need for ES.

From CQS to CQRS

To talk about CQRS in deep, especially to prove my point about its importance in a Software project, we need to introduce its “little brother”: the Command-Query Separation principle (CQS).

The Command-Query Separation principle states that a class can have 2 types of methods:

• a Command: a method that can mutate the state of the system, but doesn’t return data from the state itself - a violation of this principle is considered weak and is allowed: for example, think of a method that creates a new entity and returns the ID

• a Query: a method that returns a portion of the state of the system, but doesn’t change it in any way - no exception allowed in this case, a violation of this principle with a Query changing the state is considered strong and is forbidden

Building your classes following the CQS principle will ensure a higher quality, readability, and maintainability of our classes, with a clearer separation of concern; it’s also easier to stub/mock the classes following this principle (stubs are for queries because they only need to return a fixed data sample, mocks are for commands because they only need to verify how it is called) and in general has a lot of benefits in our code.

There is a strong relation between CQS and CQRS: basically, CQRS raises the CQS pattern to a higher architecture layer, embracing the separation between Commands and Queries at the entire application level - meaning that we want to separate Queries from Commands at an architectural level in the same way we typically keep different modules separated.

The separation can be physical or logical, but it must be clear.

Let’s try to describe a simple sample implementation of CQRS in an application:

• dedicated controllers/command handlers/data layer for the write side

  // pseudo code example - write side
  
  class Controller {
   public function addElementToList(Element $element): void;
  }
  
  class Service {
   public function executeAddElementToListCommand(AddElementToList $command): void; // used from Controller
  }
  
  class ListRepository {
   public function add(Element $element): void; // used from Service
  }

• separated data layer for write and read - this can be achieved in multiple ways but in general, you will need a way to calculate the read side starting from the right side, some examples to implement that are:

  • Database views

  • Scheduled cron jobs writing in dedicated tables/database

  • Events

  • Event Sourcing projections

• dedicated controllers/command handlers/data layer for the read side

  // pseudo code example - read side
  
  class Controller {
   public function getList(): Collection<Element>;
  }
  
  class Service {
   public function executeGetListQuery(): Collection<Element>;
  }
  
  class ListRepository {
   public function all(): Collection<Element>;
  }

💡 Embracing the low-code and no-code technologies available today, you can automate some of this to reduce the boilerplate code.

For example, what I typically do:

• when performances are not a priority, I use DB views to build the read side model with the expected fields already in place and then use a tool to expose those views automatically via REST/GraphQL (pgRest/Hasura)

• when performances matter, the calculation can be done with some async script, even better if they are triggered via Events instead of being scheduled cron jobs

• for MVPs, I’ve also handled the write side via automated REST API, for example using Supabase and having separated tables for write and read (you can also use access control rules to block writing on the read side and vice-versa)

• no-code can be useful also for building the UI, both for the write side and in some use cases for read-side data visualization

• last tip: consider Make or Zapier as tools to implement automated triggers with ease

I typically favor custom API based on feature names over REST, but since write and read are separated I can easily accept automate and standardize the less important side and focus on the most important one with the customization it needs - depending on the use case, I’ve done it on both sides and it works pretty well, reducing the codebase to maintain and simplifying things.

Make sure Event Sourcing is needed

Now, let’s introduce the villain of our story: Event Sourcing.

Event Sourcing is a pattern that mostly impacts how we handle the persistence layer of the state of our application: in a typical application, when something happens that requires changing the state, we simply change it from A to B, and then persist B as a new state. With ES, instead, we create an Event describing the change from A to B and we store the Event itself - then, an async process will execute the Events and therefore transform A into B.

As you can easily understand, this pattern has multiple positive consequences:

• we can query the Events directly

• we can rebuild the state up to a given date in the past

• we can add retroactive Events to fix the state

Event Sourcing in general is a great and powerful technique… so, why did I call it the villain of this story?

First of all, ES is costly: it has a high learning curve to learn how to implement it, and it is complex to learn how to maintain an application based on such a paradigm.

But today we are talking about CQRS, and the big problem I have with ES is the misconception it brings to CQRS: the two paradigms work very well together, therefore are usually presented and described together and most people think that CQRS only makes sense together with ES.

This is simply not true.

On one side, it’s undeniable that CQRS naturally fits with some other architectural patterns, not only Event Sourcing.

• We can easily move away from a CRUD to a task-based approach.

• CQRS fits well with event-based programming models in general.

• CQRS is a good fit already for simple domains, but it’s also great for complex domains that also benefit from Domain-Driven Design.

On the other side, it’s also very true that CQRS deserves its spotlight in Software Development, and it’s a good paradigm for building and maintaining an application with ease.

Anyway, even if CQRS brings a lot of benefits, it adds complexity to our codebase so we need to be cautious about using it: some systems fit well with an implementation based on data that is changed the same way it’s read, and in that case, adding CQRS would just add complexity without any real benefit. CQRS is a great tool to know and have in the toolbox, but even if not as complex as ES, it’s still complex enough to be used with consciousness.

Typically is a good idea to only use it on specific sections of a system instead of the entire system: a specific DDD’s Bounded Context, for example, the one where having read and write separated adds more value than complexity. One of the typical benefits of the pattern, for example, is when your system has a disparity in read and write load, because this pattern easily allows you to scale them independently.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

📚 Books

• CQRS (Command Query Responsibility Segregation) - There are a lot of misconceptions around the CQRS pattern, especially when it comes to applying it in real-world software projects. In this book, CQRS, you will learn all about CQRS with event sourcing, database configuration for reads and writes, and more.

• Microservice Patterns and Best Practices - This book will take you through different design patterns at different stages of the microservice application development along with their best practices.

• Practical Microservices: Build Event-Driven Architectures with Event Sourcing and CQRS - MVC and CRUD make software easier to write, but harder to change. Microservice-based architectures can help even the smallest of projects remain agile in the long term, but most tutorials meander in theory or completely miss the point of what it means to be microservice-based.

• Software Architecture Patterns for Serverless Systems: Architecting for innovation with events, autonomous services, and micro frontends - This book takes you through the architectural patterns that power enterprise-grade software systems and the key architectural elements that enable change (such as events, autonomous services, and micro frontends), along with showing you how to implement and operate anti-fragile systems.

📩 Newsletter issues

• CQRS Pattern: Architecture Pattern

• How the CQRS pattern changed how I think about domain modeling: part 1

• Tell, don't ask—the gateway to loosely coupled architecture

📄 Blog posts

• CQRS by Martin Fowler’s blog

• CQRS with Low-Code

• Introduction to CQRS(Working, Uses, Benefits)

• When should you use CQRS?

• CQRS Design Pattern — 5 Things You Should Know

• Understanding CQRS Pattern: Pros, Cons, and a Spring Boot Example

• How to implement simple CQRS?— Part II

🎙️ Podcasts

• 105. Event Sourcing and CQRS

• Episode 218: Udi Dahan on CQRS (Command Query Responsibility Segregation)

🕵️‍♀️ Others

• Learn CQRS

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome back to Learn Agile Practices, the home of continuous improvement and learning for Software Developers.

📌 In case you missed it

Last week in this newsletter, I sent the first part of this issue about Continuous Integration and Trunk-Based Development: there you can read the introduction to the 2 topics and the main coding patterns that you can use to hide unfinished work and therefore be able to merge and release daily, multiple times per day, with ease. If you haven’t yet, you can read it in our archive.

And for those of you who speak Italian, last week on my video podcast:

• The Weekly Pomodoro #3 - Lean Software Development

Watch episodes on YouTube here, or listen on Podcast using Spreaker or Spotify.

🔥 Available for mentoring and coaching

I’m always available for some mentoring and coaching to other software developers! Feel free to reach me: we will know each other and discuss what path can be best for you, from a free monthly mentoring path to a more frequent one or a 1-to-1 coaching service specifically on your needs!

👉 Feel free to reply to this email or reach me on any social media: all the details on my website.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

Continuous Integration and Trunk-Based Development (part 2/2): real-world examples

Introduction

Hello, developers! 🚀

Here is the 2nd part of this big issue related to Continuous Integration and Trunk-Based Development - and today, I will finally share with you 3 real-world examples where I applied the coding pattern I described last week.

This issue aims to share a concrete guide for those who want to start applying these practices to help you achieve them in your practices first, and then in daily work - so hopefully, real-world examples will make it easier to understand and spot use cases in your work to start using the patterns by yourself.

Real-World examples I applied

A food delivery API backend

The context

In a food-tech company, I was working on a Food Delivery B2B product, and I was able to work on that almost from the beginning. We had a couple of customers who were ready to take advantage of our food delivery services to offer them to their employees as an additional lunch benefit option, and we had to build the entire platform where they could place orders for the day.

As I mentioned, it was “almost” the beginning: we had a few months of work already done on a generic set of APIs that could serve any generic e-commerce/food delivery app, with way more API routes and features than we needed - but still no frontend and no clear idea of what the core of the product should be.

The use case

As you can imagine, a lot of work had to be done, and a lot of it was outside of code - but for this issue, we will focus on coding. We had to sustain the business in a better way than was done before, therefore we had three main objectives:

• build the frontend MVP

• build the missing backend APIs for the MVP

• clean up existing code (clean up here means multiple stuff: the code had a lot of code smells, tests were there but it was only integration tests at controller level, they were very brittle and weren’t testing enough, most often only 200 as HTTP response code, and some features weren’t even needed at all)

Of course, the clean-up had to be done sustainably, because we still had to serve the business to achieve the MVP release successfully and less waste possible (zero waste was impossible at that point).

The approach

We applied mainly two patterns here: Parallel Change and Dark Launch.

Since when I joined, I pushed to move into an MVP version of the software for the first release - of course, the backend would have to live with existing useless code somehow, but at least we could build the frontend from an MVP perspective and also use the set of features used in the frontend as the list of “actually required” features.

Taking inspiration from Dark Launch, we moved all the existing routes of the APIs under a useless route group that no user had access to - and then built a clean version of the active group of APIs including only useful routes. The routes were still there in the codebase, but no one could access them. This made it easy to make decisions about how to improve the code, especially when we had to clean up some code that was used in multiple places: every feature that didn’t enter the MVP phase was removed safely unless we were already sure that it was a feature that we had to include in a new release very soon (example: special rules in discount).

In some cases, we had to keep a feature: the behavior was fine but we had to refactor somehow to build a code and test we could trust… (1 ensure tests were good, 2 copy-paste the feature, 3 refactor in parallel change to test the behavior was the same)

This way, we were able to face this issue iteratively and progressively, keeping it sustainable and completely transparent to the users.

Smart Fridges iterative rollout

The context

In the same company and product context as the previous example, we also offered Smart Fridges to our customers, and one specific use case is to use it as a vending machine for healthy, high-quality products for both lunch and snacks. The UX was very smooth: you could just open the fridge via QR code with your phone, take what you wanted, and go away, and we automatically calculate what you have to pay and take it from the wallet.

The use case

After the first version release, we needed more marketing-related features like using coupons, discount codes, special offers, highlights favorites products, etc. From the user perspective, what we wanted to do is add a pre-opening screen: after using the QR code, the fridge wouldn’t open immediately anymore - instead, we show a page dedicated to the fridge, with an “OPEN” button; that page enabled us to new interactions with the customer. While from the user's perspective, it wasn’t a big change, technically it required some changes on the fridge opening and payments, basically the two most delicate pieces of the puzzle.

The approach

We approached this with two patterns in mind: Parallel change and Feature flags; but then also Branch by Abstraction came in handy.

On the backend, we applied Parallel change by creating a completely new API version for both the opening and the payment, starting from a copy of the existing one. Since the opening API became “pre-opening”, we also had to create a new API specifically dedicated to opening. These APIs were also released in production, but no one could use them because the front end wasn’t using them and we didn’t give access to anyone to those routes.

On the front end, we applied Parallel change by creating the new “pre-opening” page, which was a brand new page - it simply wasn’t used by the user flow, so no one could see it. We didn’t hide it completely (meaning that if someone guessed the URL he could have seen it) because it was in any way related to the QR code and auth strategy with the fridge, so it wouldn’t have worked anyway, and that was enough for us. If needed, we could have added a way to hide it completely.

Then, once released in production, we had to test it from a user perspective (we had unit and integration tests of course), so we implemented a feature flag at a fridge level: this allowed us to decide what to do when a user tried to open a fridge based on a variable related specifically to that fridge.

This was also a simple implementation of Branch-by-abstraction: the interface that decided which open strategy to use was based on the feature flag in this case, but still, we had an interface that was taking that decision and redirecting the user to the right strategy - we could also have a more granular approach to send only a percentage of users of a single fridge into the new strategy, but we didn’t have thousands of users so we didn’t need this level of safety.

Thanks to this flag, we were able to roll out first on our test fridge in our office and run the first tests - then, one by one, we activated the new opening on all fridges. The iterative rollout was already simplifying things, but the flag was also helpful to rollback immediately in case something didn’t work well.

Once the new feature was stable enough (in our case, we waited for a couple of weeks), we just removed the old code and the feature flags.

Feature Flag for a progressive release

The context

In a more recent experience, I had to work on a project dedicated to upgrading the database of the historical monolith database from MySql 5 to 8. In case you don’t know, with this upgrade there is an automatic cache feature that is deprecated, and our application was taking so much advantage of it that upgrading was causing a drop in performances on some of our main pages for SEO: we couldn’t afford that.

The use case

From the beginning, I was very concerned about the work to do because the codebase wasn’t covered by enough tests, and we couldn’t trust the existing ones - I also didn’t have confidence in that codebase either because I was new.

What we had to do in practice was replace the (dozens of) queries from the most important pages for SEO with a single GET read operation from REDIS: an async data calculation would have prepared the required JSON structure to replace the queries.

Some problems: no one had enough knowledge to build a JSON sample, so we had to build it step by step, and no one was aware of what data from those queries was used - we were pretty sure that a lot of fields were unnecessary since most queries were getting all the fields from all the tables, but we couldn’t understand which ones were unnecessary upfront (and even if we could do it, it would have taken ages).

The approach

An iterative, exploratory approach was the only safe way here but we also needed a way to test the changes (non-regression kind of testing, since it’s like refactoring work here).

Again, Parallel Change, Dark Launch, and Feature Flags were our safety net here.

We put together those patterns to build a cascade structure:

• via Feature Flags at a page level (a simple boolean value on a database configuration table) we could decide for each page if the data was coming from DB or Cache (with a Strategy Pattern implemented on code through the Feature Flag)

• via Parallel Change, we handled some shared code that was unsafe to refactor by copy-pasting it in a version dedicated to cache, where we replaced DB queries with data from cache - once it was stabilized as a good solution, we removed the duplication

• and, last but not least, in a sort of a Dark Launch approach, we also implemented the Cache strategy in a way that catches any Exception that might happen in the process: if that happens, we log the exception (so that we could collect all the data issues to fix) and then we transparently fallback to the DB strategy so that the page keeps working from the user perspective

Again, some additional work during development put us in a situation where we were able to avoid any real big issues to reach production - we had some small issues, but it was easy to handle them because the user wasn’t seeing anything weird, and we could always turn the flag OFF if needed.

Conclusions

As you might have noticed, one pattern does not appear in the examples I chose: the reason is that I mostly used those in more simple situations.

For example, I used the Keystone interface sometimes to release a new API without setting up the route where the Controller would respond; sometimes it’s even enough if the frontend is built after the backend, so you can just release the new API but no one can use it. This is useful when we work with separated frontend and backend task (I usually share the API contract before, and release a stub respecting that contract, to enable async releases of backend and frontend - just be careful to replace the stub with the real implementation before allowing the users to see this) but it’s also helpful when we work in Pair/Mob Programming (in this case, we can just build the API on the backend and then work on the frontend after that).

Branch by abstraction has a small example, but it’s the best I can provide from real experience - in any case, you can use it together with Parallel change to build a class that behaves as a sort of Load Balancer between old and new logic, and even configure how many requests to direct to the new logic.

In general, such techniques are powerful and pretty useful, and I strongly suggest everyone that who wants to become a Senior become confident in them because they are great ways to avoid issues in production in a safe way.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

📚 Books

• Continuous Integration: Improving Software Quality and Reducing Risk - The authors first examine the concept of CI and its practices from the ground up and then move on to explore other effective processes performed by CI systems, such as database integration, testing, inspection, deployment, and feedback.

• Trunk-Based Development And Branch By Abstraction - An all you need to know reference book about trunk-based development, Branch by abstraction, and related software development practices. Many diagrams throughout, and a sections on working out how your company can get from where you are to trunk-based development, CI, CD, and all that comes with it.

• Feature Flag Best Practices - With this practical book, software engineers will learn eight best practices for using feature flags in production, including how to configure and manage a growing set of feature flags within your product, maintain them over time, manage infrastructure migrations, and more.

📩 Newsletter issues

• The Difference Between Design Thinking, Lean Startup, and Agile [Strong Opinions, Weakly Held]

• Feature Flags [Refactoring]

• The Road To Continuous Deployment [SaaS Engineering]

• Branch based vs Trunk based development [Git Better]

• Why are we so afraid of Trunk-Based Development? [Learn Agile Practices]

📄 Blog posts

• Continuous Integration by Martin Fowler’s blog

• HOW TO BRANCH BY ABSTRACTION WITH FEATURE FLAGS

• Evolving Your React App Safely with Feature Toggles and Branch By Abstraction

🎙️ Podcasts

• Trunk Based Development vs. Gitflow [The Rabbit Hole podcast]

• Trunk-Based Development And Feature Flags With EJ & TJ [The CTO Studio]

• Ep. 5: Trunk-Based Development [The Continuous Delivery Podcast]

• A conversation about trunk-based development [Tiny DevOps podcast]

🕵️‍♀️ Others

• MinimumCD [Reference website for Continuous Integration and Deployment/Delivery]

• Trunk-Based Development [Reference website for TBD]

• Just commit to master, please - Hot to actually implement CI [My talk slides]

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome back to Learn Agile Practices, the home of continuous improvement and learning for Software Developers.

📌 In case you missed it

Last week in this newsletter, I wrote about Lean Thinking and Lean Software Development: starting from Toyota Production System, I shared with you the impact of applying Lean to software, what principles it suggests, and the positive outcomes of applying them. If you haven’t yet, you can read it in our archive.

And for those of you who speak Italian, last week on my video podcast:

• The Weekly Pomodoro #2 - OOP Misconceptions

Watch episodes on YouTube here, or listen on Podcast using Spreaker.

🔥 Personal Coaching

If you want to speed up your growth as a software developer with Agile practices such as TDD and Clean Code, you should consider my coaching service: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of my First Lesson Free policy: enjoy the first free session and get to know me to see why I am the right person for you to improve your professionalism as a software developer.

Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

Continuous Integration and Trunk-Based Development (part 1/2): coding patterns

Introduction

Hello, developers! 🚀

Since I started this newsletter, I’ve talked of a lot of topics related to programming, Agile practices, and the work of a Software Engineer in general - but for sure, there are some of them that I talked about much more than others, with the top 3 probably composed by Test-Driven Development, Continuous Integration, and Trunk-Based Development.

Today, we talk again about the last two: after a quick recap of what they are about, I will share with you the coding patterns that enable CI and TBD by hiding work in progress and some real-world examples where I applied those practices.

This issue aims to share a concrete guide for those who want to start applying these practices to help you achieve them in your practices first, and then in daily work - the coding patterns tips will be simple but clear, enough to clarify the approach and start practicing it.

In this first part, we will introduce the topics in short, and then deep dive into the coding pattern I want to talk about. Then, next week, in the 2nd part, I will share 2 real-world examples where I applied those patterns in my experience - with my final reflections on the topic.

I wanted to put some code examples, but this kind of pattern requires a lot of context to build a meaningful use case, and it would still be hard to understand only by reading, so I thought it wasn’t worth it and gave up the idea.

The principles

Continuous Integration is one of the most powerful concepts to master in the Software Development World, probably the one that most impacted how I see this job.

CI is the activity of very frequently integrating work to the trunk of version control and verifying that the work is, to the best of our knowledge, releasable.

Implementing Continuous Integration implies some practices that are embedded into it, and one of those practices is Trunk-Based Development.

Trunk-Based Development is a methodology where changes to code are integrated directly in the main branch, without any other branch in the middle, at least once per day.

If you want to implement CI in your workflow, you must start using the set of practices that together make CI, including Trunk-Based Development: in other words, you can’t say you do CI if you don’t do TBD.

Sadly, that’s what most company does, at least in my experience - they use feature branches, typically with a very long life of multiple days, and then think they are doing CI just because they have an automated pipeline.

That’s just wrong.

Anyway, when it comes to the idea of very frequently integrating work to the trunk, where very frequently means daily or even multiple times per day, the typical concern is: how do we hide work in progress if I have to merge unfinished work to master (and even release to production, if I also want CD)?

There is a great quote I agree with, about this topic. The quote comes from Bryan Finster, who as a guest on an issue of the Crafting Tech Teams newsletter once said:

Software Developers have been trained to deliver complete features. That’s the problem. It’s one of the hardest habits to break.

That is so much true!

90% of software developers I know have this bias: we were taught to release fully completed features, and see the release of the software as the last piece of a long process instead of part of the daily work; this habit makes the question about how to hide work in progress seems to be a very hard and complicated question to find an answer to.

The reality is that this is a problem that has already been solved: there are multiple patterns that we can use to keep the work in progress hidden from the user, allowing us to release our code without any issue on their side.

We will dive into the most common patterns in a while, but I want to point out an important thing before; let me share a quick example with the most known pattern to hide work in progress: Feature Flags. A basic implementation could be as simple as a boolean value in the configuration, at a user level, that allows you to decide if a user has access to that feature or not; this has some consequences on code implementation, of course, because you’ll have to handle this configuration value to decide whether to execute the behavior or skip it.

From this example we can highlight a characteristic that is shared by all the “work in progress hiding patterns”: it will probably require some additional work to hide the work in progress; we have to think about how to hide it and make some coding to achieve this purpose.

So the question here is: is it worth it?

Of course, it is, and the reason is quite simple: the investment we take to hide our work in progress and enable the release of our code is completely repaid by the unplanned work we will avoid after the release; it is proved that implementing CI in our daily work will drastically reduce the unplanned work we will face later on during the process of completing the feature.

Maybe you remember it from our Lean Software Development issue, but let’s say it again: unplanned work is one of the biggest sources of waste in software development, therefore reducing it should be one of our targets.

Here, we are reducing unplanned work thanks to a little additional, but plannable, work: it means we are investing 1 today to be sure to not waste 10 tomorrow; we are accepting a bit of additional conscious work, that we are aware of and therefore is plannable, to ensure we avoid some unplanned, unexpected work later that will cause waste, issues, waiting time and context switch to be solved.

As always, if you want to deep dive into such topics, you will find a lot of useful resources in the Go Deeper section at the end of this issue.

Coding patterns

Keep the API Hidden

The pattern

The easier way to hide code to be executed or noticed in production is to hide its interface: just make sure that the path to the feature is either hidden to the user or the last piece you release. In a well-designed system, such interface elements should be minimal and thus simple to add.

Practical Tips

1. Hide (or release last) the route of the API - I typically like to do this with a stubbed response that respects the real contract

2. Hide (or release last) the UI that enables the user to interact with the feature (it can even mean hiding an entire component or page)

Feature flags

The pattern

A boolean value, typically based on a constant, a parameter, or a configuration value, that a class can use to decide if we want to execute path A or B: this is basically what Feature Flags are. This is a simple way to be able to activate the new behavior for testing, while it’s still disabled in production.

Practical Tips

• Build a Feature Flag class or use an existing library (an example here) - some tips:

  • prefer Strategy pattern to implement the two different paths

  • be careful to pick the granularity you need for the flag: if it’s too big it can become useless, if it’s too small it can become too complex to maintain, so make sure it’s worth it

  • Feature Flags are temporary most of the times (at some point only one of the 2 paths usually survive, whether it was an experiment or a change) so be sure that the implementation is also easy to remove

• Make sure that you can enable/disable the flag quickly: if your release process is fast enough, even changing code can be fine - otherwise favor a DB table configuration or something else that allows you to do it in seconds

Parallel change

The pattern

Also known as expand/contract, these patterns suggest expanding the current code instead of changing it: for example, if we have to rename a database field, we should:

1. create a new one instead

2. start writing in both fields

3. copy data from old to new field

4. start reading from the new field

5. remove the old field, now unused

This allows us to make each of those steps reversible easily, something impossible if we directly change the name of the column.

Practical Tips

• The main objective when doing a change is to make it safe, ensuring we can rollback in case of issues, and avoid the need for synchronous changes with clients.

• Another example is creating a new version of a public API:

  • release the new version first, while still keeping the old one

  • ensure that no one uses the old one anymore (providing a deprecation date might be good enough in most cases)

  • remove the old version of the API

• The idea of Parallel Change is pretty flexible: in general, stop thinking of software development as changing code, and think more of it in terms of expanding what exists first, and then removing what’s not needed anymore

Dark Launch

The pattern

When you have to add a new behavior, you can make the code execute this behavior without impacting the existing one: this way, it will be invisible from the user's perspective, nothing has changed from his point of view - but in reality, you are executing that code in production to test its impact and monitor things like performances or saved data.

Add your behavior, and just ignore the results from the application point of view - but log or save any info about what has been done when it goes well, or what happened when it broke up.

Practical Tips

• This pattern best suits use cases where the new behavior is enhancing something already existing that doesn't require any additional interaction from the user.

• Ensure that the “dark” code is under a try/catch that handles all errors: this way, you can save all the info you need from the error (in logs or everywhere else you might need it) and allow the code to move on without breaking

  function foo(): void {
     // do something before
     try {
         // execute the new behaviour here
     } catch (Throwable $exception) {
         // save the data you need about the error, then let the code move on
     }
  }

Branch by abstraction

The pattern

The idea here is that we can introduce a different alternative behavior, but instead of making it used by everyone immediately, we use an abstraction layer to route only part of the requests to it: it can mean that only a specific component uses the new behavior at first, or just a percentage of requests.

Thanks to this approach, we can iteratively roll out the change and increment the usage until it replaces the old behavior completely.

This pattern has some similarities with Parallel Change: the main difference is that here we progressively go from old to new behavior, while in Parallel Change it’s more of a direct switch after the two behaviors live together.

Practical Tips

• If the code you need to change is used directly by others, build the abstraction layer first

• If you are doing this on some legacy or badly tested code, you can take advantage of the abstraction layer to add tests to that behavior

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

📚 Books

• Continuous Integration: Improving Software Quality and Reducing Risk - The authors first examine the concept of CI and its practices from the ground up and then move on to explore other effective processes performed by CI systems, such as database integration, testing, inspection, deployment, and feedback.

• Trunk-Based Development And Branch By Abstraction - An all you need to know reference book about trunk-based development, Branch by abstraction, and related software development practices. Many diagrams throughout, and a sections on working out how your company can get from where you are to trunk-based development, CI, CD, and all that comes with it.

📩 Newsletter issues

• The Difference Between Design Thinking, Lean Startup, and Agile [Strong Opinions, Weakly Held]

• Feature Flags [Refactoring]

📄 Blog posts

• Continuous Integration by Martin Fowler’s blog

• HOW TO BRANCH BY ABSTRACTION WITH FEATURE FLAGS

🎙️ Podcasts

• Trunk Based Development vs. Gitflow [The Rabbit Hole podcast]

• Trunk-Based Development And Feature Flags With EJ & TJ [The CTO Studio]

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome back to Learn Agile Practices, the home of continuous improvement and learning for Software Developers.

📌 In case you missed it

In the first issue of 2024 last week, I shared my objectives for this year, with some spoilers on what to expect from this newsletter. In case you missed it, check it here.

Also, for those of you who speak Italian, my video podcast is back! Two episodes are already out:

• The Weekly Pomodoro #1 - Async work

• Dev Debate #1 - Async work with Jaga Santagostino & Simone D’Avico

Watch them on YouTube here, or listen on Podcast using Spreaker.

🔥 Personal Coaching

If you want to speed up your growth as a software developer with Agile practices such as TDD and Clean Code, you should consider my coaching service: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of my First Lesson Free policy: enjoy the first free session and get to know me to see why I am the right person for you to improve your professionalism as a software developer.

Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

Lean Software Development

Introduction

Hello, developers! 🚀

Today we talk about one of my favorite stories: Lean Thinking was born in the 40s in Toyota in the attempt of the Japanese company to become a leader in the automotive world business. This attempt will be successful and will build the legend of the Toyota Production System and its inventor Taiichi Ohno.

Ohno realized that the main issue of Toyota was that they were used to a PUSH mass production approach because this was the successful approach they were used to when creating military means. The Japanese car market didn’t have the same size and requirements, of course, so he brought the idea to shift to a PULL production approach, driven by customer demand.

The Toyota Production System has become legendary and it’s still evolving and in use today, its main goal is to reduce waste over the entire flow of work, and its main characteristics are:

• The right process to produce the right results: a pull system to avoid overproduction and balance workload, building a culture of stopping to fix problems and getting quality from the start

• Add value to the organization by developing your people and partners: grow leaders who can then teach others, develop exceptional people and teams, and help your partners and suppliers improve

• Continuously solving root problems drives organizational learning: go and see for yourself to understand the situation, make decisions by consensus considering all the options, and build a learning organization

What this means is that it is a system for thorough waste elimination. Here, waste refers to anything which does not advance the process, everything that does not increase added value. Many people settle for eliminating the waste that everyone recognizes as waste. But much remains that simply has not yet been recognized as waste or that people are willing to tolerate. [Wikipedia]

Lean Thinking is the methodology born from the Toyota Production System: since TPS worked well, it has been used as a model to build a framework to replicate the same principles in different types of companies, businesses, and contexts.

From manufacturing to software

In a progressive process, Lean Thinking was taken as inspiration and transposed from the manufacturing to the software world, because smart people started to notice that there is much that the software world can learn from Lean manufacturing - a good (invented) story about this is the book “The Phoenix Project”.

In 2003, Mary and Tom Poppendieck wrote the book “Lean Software Development”, where they formalized the idea of Lean applied to Software, describing the 7 principles they based it on:

1. Eliminate Waste

2. Amplify Learning

3. Decide as late as possible

4. Deliver as fast as possible

5. Empower the team

6. Build integrity in

7. See the whole

In a similar way to XP, since principles are pretty high-level, they went deeper with each of those to give some more low-level and practical description of what they meant.

Eliminate Waste

Eliminating waste is the most fundamental lean principles.

Software development has multiple types of waste, and the first step is to understand how to recognize them:

• unreleased work

• obsolete or unused features

• defects and bugs

• context switch

• waiting time

• handoffs

• unnecessary processes or documentation

• management activities

Eliminating waste is definitely the place to start, and the main activity to achieve this target is to measure the lead time: you should map the high-level process from the idea to giving value to the customer, and then measure the time of this process including both work and wait time; this is the lead time, and once you are measuring it your objective is to pick the biggest opportunities to increase flow and reduce the lead time (theory of constraints) and implement it - then measure again to confirm the improvement, and move on with the next bottleneck.

Amplify Learning

Generate the most knowledge at the least cost possible.

Software Development is most often a learning process, so we should embrace that it involves trial and error and handle it by consequence, for example:

• make sure feedback loops are in place and at the highest speed possible

• keep synchronization high: integrate code changes in small batches and make it fast to build and test the system (CI)

• work in (short) iterations delivering the highest priority item first and then get feedback

• Talk about constraints instead of solutions, and allow the obvious solution to emerge by getting feedback on multiple options

Decide as late as possible

The target is a robus, change-tolerant design for the system so that it can be readily adapted to most likely changes.

We need to avoid that changing code becomes always harder because of new code, and to do that we need to favor emerging design over time. To achieve this target, we want to decide as late as possible following 3 main principles:

• Options Thinking: make decisions under the road, delaying irreversible decisions until the uncertainty is gone (or reduced to the minimum); be open to doing something new in the future without building it before it’s needed and improve your skills in understanding what options are worth to keep open

• Last responsible moment: delay decisions until failing to make a decision removes important alternatives - to delay commitment, favor abstractions over specific representations, separate interfaces from implementations, and use feature flags; the only decisions to take early are those that facilitate design to emerge

• Making decisions: plan work without predicting it, and use simple principles or guidelines to enable decision-making by the people closest to work.

Deliver as fast as possible

The faster is delivery, the longer decisions can be delayed.

Delivering fast is important to reduce the feedback loop and reduce the weight of reversible decisions; to optimize speed without dropping quality, there are three main pillars to follow:

1. Implement a pull system, where customers pull the work instead of a schedule pushing it; use Kanban to visualize the work so that everyone can see what’s going on.

2. Follow queuing theory to reduce cycle time: split incoming work into small batches, prioritize work regularly, make people focus on bottlenecks, and limit variability in work; the target must be to optimize for quicker cycle time instead of people utilization, so you should always leave enough slack in capacity and a parallel independent stream of work.

3. Delays have a cost so we want to reduce it: give the team a simple, economic model, empowering it to make tradeoff decisions by putting a price tag on delivering vs delay; avoid trades of time vs scope vs money by making it all about money.

Empower the team

Give people the power to decide for their work, but also invest in developing their capacity of making decisions.

Decisions should be at the lowest level possible to ensure they are contextual and fast. You should empower the team by helping people to develop some characteristics: the team should feel responsible for their own work (including processes, practices, quality, etc), while managers should listen to the teams and help them remove organizational blockers but also coach them.

Allowing the team to commit together to achieve their objectives, celebrating successes, and allowing for mistakes will make people more motivated and committed, which is one of the objectives of leadership: set direction and lead, don’t manage.

Finally, ensure that the expertise of the team always grows over time: encourage experiments and continuous training and learning, favor sharing sessions to spread the knowledge gained, favoring conversations over documentation) and build internal communities of expertise.

Build integrity in

Integrity is a key differentiator.

We need to build great product integrity that must be perceived in the eyes of the customers - this integrity is built by multiple pieces:

• Clear communications with customers: we need to ensure that the communication flows between customers and the team in both directions; it must be easy to receive feedback about the last iteration, but also to keep customers updated on what’s new; customer’s problems should always be kept as a priority when making decisions, supporting the team in achieving and maintaining a deeper customer understanding.

• Clear communications within the team: ensure that the core concepts of the product belong together, and enable a regular flow of information between everyone working on the product, making it easy to discuss and solve problems together.

• Continuous refactoring: foster a clean code culture to reduce the cost of refactoring and enable refactoring code daily to maintain the codebase under control; allow design and architecture to evolve so that you can delay decisions also on them; to ensure you refactor only where it’s worth it, try to refactor a piece of code right before it needs to change.

• Testing: help the team in improving their testing knowledge and skills to ensure they use all the best possible testing techniques, from unit to e2e tests; ensure testing is automated, and use acceptance tests as a tool to ensure customer needs are met.

See the whole

The ability of a system depends on how well the parts work together.

We should always strive to improve the whole system and not the single parts: the focus when removing constraints, addressing problems, and measuring results should be on the entire system and not on an individual level.

Avoid measuring locally, because you want to optimize the whole and not just a small part: measure group productivity, not individual one - we want to win a marathon, not only a section.

When writing contracts with supplies and vendors assume good intent, and limit damaging behavior through relationship, not the contract, favoring a kind of contract that shares goals instead of fixed price ones.

A successful model for businesses

After all this history about Lean, and considering the words I use to talk about it, it’s probably quite clear that I love the Lean approach: it’s just a perfect match with the Software Industry and it should be much more considered.

The first time I heard about the Toyota Production System and Lean was in the Phoenix Project book: a narrative/tech book that tells the story of Bill, an IT Manager at a company called Parts Unlimited. Bill is responsible for a project that is fundamental for the future of the company but it’s massively over budget and later (codename “Phoenix”): he has 90 days to make it successful, otherwise the entire department will be outsourced. Luckily, he will receive the help of Erik, a new board member who shares his knowledge of TPS, Lean, and DevOps with Bill.

Through Erik, the authors make this book much more than simply a fun narrative about very common historical issues of the Software industry: through the story, you can learn the basics of those methodologies - and this book does not only have a sequel (The Unicorn Project) but also a strictly related book named The DevOps Handbook, a more classical tech book from the same authors that deep dive into the methodologies used in the story.

I was already into Agile and XP at that point, and I knew the basic principles of DevOps - I was fascinated by the story of Toyota and the Lean methodology, especially because it’s pretty clear that Agile, XP, Lean, and DevOps share a lot: to be honest, I treat them as a family.

Once you deep dive into Lean Software Development, you can either be fascinated or horrified I guess - based on which kind of professional developer you are: to me, a born team player who LOVES the team dynamics of collaboration practices such as Pair/Mob Programming, the focus on the entire system and not on individuals not only makes a lot of sense (that should be objective…) but also motivate me a lot.

Thanks to Lean, I learned to focus on flow and became interested in topics such as reducing work in process, especially the “extreme” version of it: Single-Piece Flow, where we can only work on one thing at a time - I even dedicated an old issue of the newsletter and a talk to this topic that seems so revolutionary in a world where multi-tasking is considered somehow the standard, completely ignoring how our brain works.

The 7 Lean Software Development principles I described above describe the way I see software work in a way that is probably even better than what Agile and XP can do because they mostly focus on team and company as a system, and if there is one thing I can say is that if the system doesn’t work you will fail, no matter if you have the best people in the team: there’s no way out.

Also, the Toyota story is a good conversational tool when you are trying to sustain the introduction of practices: the idea that a big company such as Toyota thinks that it’s a good idea to introduce the Andon cord to allow anyone over the entire production line to stop the entire line if something breaks up is incredibly powerful; making people responsible for the quality, and when something happens everyone focuses on the problem, instead of continuing the work on the working parts, not only enable a quicker fix of the problem but also avoid to accumulate work in the broken part of the system that would cause a slower restart when the fix is done - therefore, stopping all the work is better because it reduces the overall waste.

The first time I understood this, it was mind-blowing.

Lean is even more fascinating to me than Agile and XP, and this was a surprise for me: now I think the reason is that XP and Agile were made by developers and only after reached also other businesses, so they might be perceived as biased, especially when trying to foster them with skeptics or non-technical people.

Lean, on the other hand, did the opposite way: it was born in the manufacturing world, and only after it reached the Software world. This has some positive side effects:

• it’s far easier to have concrete examples that it works, and Toyota is just the biggest example of them all - this makes the conversation with non-technical people far easier

• It has an intrinsic match with businesses (reducing waste, we reduce costs and will more likely be successful and obtain more profit) and therefore the Software implementation of Lean seems more understandable to business people

I strongly believe that Lean is an amazing methodology to use in both business and software, and I hope that Lean Startup and Lean Software Development methodologies will keep growing in popularity because this can only bring positive side effects to our world.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

📚 Books

• The Toyota Way - A classic in the world of business management, The Toyota Way has been helping leaders create powerful strategies based on the automaker's legendary management principles and philosophy for nearly two decades.

• Taiichi Ohnos Workplace Management - This unique volume delivers a clear, concise overview of the Toyota Production System and kaizen in the very words of the architect of both of these movements, Taiicho Ohno.

• Lean Software Development - In Lean Software Development, Mary and Tom Poppendieck identify seven fundamental "lean" principles, adapt them to the world of software development, and show how they can serve as the foundation for agile development approaches that work. Along the way, they introduce 22 "thinking tools" that can help you customize the right agile practices for any environment.

• Implementing Lean Software Development - While the previous book provides an introduction, theoretical advice, and a reference to Lean, this follow-up incorporates their gained knowledge and understanding of what works and goes steps further to provide hands-on guidance for implementing a Lean system.

• The Phoenix Project - The CEO demands Bill must fix the mess in ninety days or else Bill’s entire department will be outsourced. In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they’ll never view IT the same way again.

• The DevOps Handbook - Technology is now at the core of every company, no matter the business model or product. The theories and practices laid out in The DevOps Handbook are tools to be used by anyone from across the organization to create joy and succeed in the marketplace.

📩 Newsletter issues

• The Difference Between Design Thinking, Lean Startup, and Agile [Strong Opinions, Weakly Held]

• Examples of the hidden wastes of software development [Bit Byte Bit]

• ✋Stop Overcommitting and 🚚 Start Delivering: The Benefits of WIP Limit in Software Development 🧑‍💻 [Learn Agile Practices]

📄 Blog posts

• Book Summary for Lean Software Development

• Toyota Production System : 14 Solid Principles

• 13 pillars of the Toyota Production System

• What is Lean Software Development (LSD)?

🎙️ Podcasts

• #91 - Lean Software Development Principles and Mindset - Mary & Tom Poppendieck [TechLead Journal podcast]

• Lean Software Development - It’s About Uncertainty! (Healthy Software Developer podcast)

• Podcast S3E05: Lean Software Engineering [The Burn Up - Agile Software Delivery podcast]

• The Toyota Production System podcast

👨🏻‍🏫 Online courses

• Lean Software Development Fundamentals [Pluralsight]

🕵️‍♀️ Others

• Toyota Vision

Happy 2024, developers! 🚀

A new year has arrived, and every year I start my content production by sharing publicly my plans and objectives for the year, in this case specifically for Learn Agile Practices. You will find spoilers about new types of content and formats, the evolution of existing formats, and my personal learning plan related to my professional growth.

As always, the target is double: on one side, sharing these objectives will motivate me more in trying to achieve them, but on the other side, as always with any of my content, I hope that these objectives might inspire and be useful to you all.

Let’s start!

Learn Agile Practices evolution

The most important element of LAP currently is the newsletter, and this will remain true because it’s the main content I do in English and this is important for me - anyway, an evolution in the format is required from my point of view.

In the latest issues, I noticed that I felt the desire to invest more time into my take section, and less time into the introduction; this not only made it harder to write but also caused the two sections to be a bit mixed compared to the past; because of this, I decided to simplify the newsletter and just write everything in a single section, where I will for sure introduce the topic but will put more focus on my point of view and reflection on it. The Go Deeper section will remain: I consider that one of the identifiers of my content: there’s always a way to deep dive into a topic if you are interested, and helping in doing that is an important objective of my content.

The biggest news from a content production point of view is that I will be back with Youtube videos and podcasts: by the end of January I will be back with a video podcast series of episodes that will be available both on video and podcast, but it will be all in Italian, at least for now. This is mainly because it’s easier for me to create such content without too much preparation if I use my natural language, and it's also easier to invite other developers to a monthly interview special edition episode that I plan to start. I want to bring 2 main formats to my video podcasts:

1. The Weekly Pomodoro: one topic, 25 minutes available for me to talk about it. Weekly on Thursday, the first episode will be out on the 25th of January

2. The Debate: a monthly episode coming out on the last Wednesday of each month, in addition to the weekly one; I will deep dive into a hot topic (typically introduced in the previous Weekly Pomodoro) with one or more guests that will either disagree with me about the topic or be an expert on it that can share some insights with us.

You can subscribe to my YouTube channel here and see on which platform the podcast is available here to follow.

Then, let’s talk about my services: personal coaching service will remain available - all the previous coaching has been completed and I’m thinking of evolving this service but for now is available in the same format: 699$ for 12 one-hour lessons, with a First Lesson Free policy (enjoy the first free session and get to know me to see why I am the right person for you to improve your professionalism as a software developer) and also remember that you have access to dedicated discount as a subscriber to this newsletter, just contact me to discover more.

But the main service I will focus on this year is my TDD & OOP Workshop: the first edition last year was a great success, with 8 participants in a 4-hour practical session and very positive feedback. I plan to repeat at least 3 more free versions of the workshop in the first quarter of 2024, to keep improving the format, and then start offering a paid version in the second half of the year, both online and in person (somewhere in Milan).

The best way to remain updated on all my initiatives, in addition to this newsletter, is to follow me on LinkedIn here.

My learning plan

I’ve reflected a lot on my learning plan for this year because there are multiple topics that I’m interested in - hopefully, the plan is not impossible to achieve:

1. First of all, I want to go even more in-depth with my knowledge about OOP and TDD, meaning not only improving even more with the practices but also expanding the list of OOP programming languages I know. My plan here is to deep dive into books like: “Clean Code”, “Growing Object-Oriented Software Guided by Tests”, “Working Effectively with Legacy Code”. On the other side, I will study multiple programming languages: Typescript (I already know it and worked with it for a couple of years, but I don’t work with it now and I want to go deeper with it, but also Go, Rust, and Ruby. The idea here is to read the documentation and use some tools:

   1. Exercism to move the first steps with Katas of raising difficulty

   2. Code Challenges newsletter from John Crickett, to raise the level with more structured projects

   3. CodeCrafters to make the most realistic project possible creating clones of Redis, Docker, or other famous existing products

   In the end, I will probably pick one of those languages, the one that I liked the most, to dive even more into it with a book and an even bigger side project.

2. Functional Programming: I want to start learning this paradigm, that I already faced and worked on for a year in 2020/2021, but it has been a while and not much knowledge has remained on me so it’s like I have to start from scratch. The plan is to do this in the second part of the year, and I will probably start by following Giulio Canti’s course guide in this repository (I had the pleasure to participate in one of its courses and this should help me remember most of it), then I will probably go with “From Object To Functions”, a book that has been strongly suggested to me. Finally, I will probably also read Domain modeling made functional.

3. Public speaking: in 2023 I experienced my first talk at a conference, and in the entire year I had 3 talks in Meetups and 1 talk at a big conference (Italian Agile Days). I love that, so I plan to take more talks and participate in more conferences this year, and I would also like to invest some time in learning public speaking. I’m still exploring the how, what, and when of this, so if you have any suggestions please feel free to contact me!

That’s it with my 2024 goals, let me know what you think and what are your goals!

Before saying hi, here is a short spoiler recap of the following appointment with LAP:

• The podcast returns, in Italian and also on video, with new episodes starting in 2 days:

  • 25th of January - The Weekly Pomodoro: Why I don’t like async work

  • 31st of January - The Debate: Async work w/ Jaga Santagostino & Simone D’avico

  • 1st of February - The Weekly Pomodoro: Object-Oriented Programming Misconceptions

• Next week in this newsletter → Lean Software Development

• On February, specific date tba: 2nd edition of my “TDD & OOP” Workshop Online, 6 seats available

The best way to remain updated on all this stuff is to remain subscribed to this newsletter and follow me on LinkedIn here. Always feel free to contact me for any questions or needs, I’m also available for some mentorship and support in general, and always happy to help if I can!

Until next time, happy coding! 🤓👩‍💻👨‍💻

Hello, developers! 🚀

Another year has come to an end, and it’s the first year of this newsletter, that started the 20th of January this year with the first article: Why Agile is important?

Today, I want to share with you my personal retrospective on this years, considering all aspects of my professional life as a Software Engineer and Content Creator, and in the first issue of the year I will also share my objectives for 2024.

The reason to share this kind of stuff is that sharing is a great way to both celebrate success (and you will hopefully celebrate with me!) and also commit to the new objectives and make them more concrete. It’s a great way to find motivation, and I’ve started doing this since 2020 when my content was only Italian.

I will be short, I promise: let’s jump into it!

Happenings and Achievements

This year, I started the Learn Agile Practices journey: LAP currently is made by this newsletter, but in my head, it’s already clear how to evolve it and to make it become much more: more types of content (audio/video) and a technical coaching service for developers (personal coaching always available, but also free sessions and workshop).

In this first year, the result was pretty good! I reached 54 subscribers to the newsletter, and 129 subscribers to my Youtube channel. I offered my first free TDD Workshop, which was a great success, and I was able to speak at a great conference such as the Italian Agile Days 2023, but also to a couple of meetups - and I’m particularly proud of my talks! In addition, a collaboration with Codemotion started: I will write a monthly article in Codemotion Magazine (in Italian) about Agile practices and methodologies, the first one will be out before Christmas!

It was a great first year, and hopefully, the next one will be even better!

In case you missed them, these were the top 2 most read articles from this year:

• Choosing Wisely: When to Go Sync ⏳ and When to Go Async ⏰ in Software (109 views)

• ✋Stop Overcommitting and 🚚 Start Delivering: The Benefits of WIP Limit in Software Development 🧑‍💻 (107 views)

From a professional point of view, I kept investing a lot of time in learning and continuous improvement, focusing on different objectives: improving my approach to learning, improving my communication skills, and deep dive into top Agile practices such as Refactoring, TDD, etc.

This is the list of the books I read (or studied) in 2023:

• Non-violent communication → a nice framework for effectively communicating things without hurting people, especially when expressing negative feedback or critics

• Practice Perfect → a wonderful book about coaching techniques and best practices, useful from both perspectives of the teacher and the learner, and therefore useful for when I’m learning but also when I’m coaching

• Refactoring → a milestone about how to approach refactoring effectively; the most relevant part, IMHO, is that refactoring can only happen if we have tests to validate that the behavior doesn’t change - and that refactoring should be a daily habit, not a special occasion

• Practices of an Agile Developer → a cool book that is a quick trip around all the best technical practices known today; a great refresher of all of those, with some gems and personal examples from real experience

• Accelerate → by far the best book I read this year - the moment I discovered that a book based on research that proves that techniques such as TDD and CD have a positive impact on business exists, I knew I had to read it, and it was amazing as expected; the info in this book is the best argument existing to support why such practices should be implemented in every company

From a career point of view, I realized one of my objectives: working from home for a foreign company outside of Italy. I currently work for TourRadar, a travel-tech company based in Vienna: a company with such a great culture and passionate people, and I’m very proud to be part of it.

Learnings

It’s good to rethink what happened and fall into a bit of nostalgia, but the main reason to do it is to learn something from it - so here is what I learned this year:

• I love speaking in public. I like it and I want to invest some learning time in it to improve my public speaking skills, for sure.

• I prefer sync software development: async work is a thing today, especially when working remotely, but I think we are overusing async - especially for refinements, brainstorming, and software development, I love sync conversations. Refining a feature or request is easier with a conversation, same as pair/mob programming is better than async PRs.

• I believe I have some entrepreneurial spirit: I don’t think I will ever jump into my own startup unless I find an idea that makes me fall in love, but I would love to jump into a startup as the first and only developer at the beginning, for sure!

• After a lot of learning about practices and methodologies (and much more to learn, especially about ATDD, BDD, and DDD), I think it’s probably time to enlarge my portfolio of languages

See you in 2024

And that was my wrap for the 2023 year of myself and Learn Agile Practices! Hope you liked it, feel free to share your learnings of the year and any feedback or suggestions about LAP!

The newsletter will be back on the 16th of January, with the first issue exploring my objectives for 2024 and presenting all the news that will come - then, we will jump back into content with a great topic: Lean!

Until next time, Merry Christmas, Happy New Year, but most of all, Happy coding 🤓👩‍💻👨‍💻

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome to the home of continuous improvement and learning for Software Developers.

📌 In case you missed it: in the last issue, I got inspired by my talk at IAD 2023 about CI and Trunk-Based Development, and specifically from a question I received about this year's State of DevOps Report that suggests that Trunk-Based Development might increase the burnout: I was skeptic, so I took the report and read it in deep, and then I wrote my thought about it. In case you missed it, check it here.

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

My personal 2023 directory of AI & No-Code tools 🤖⚙️

Hello, developers! 🚀

First of all, a small announcement: this is the last “content-focused” newsletter of the year - what I mean is that next week I will share a personal retrospective of 2023, a short recap of what I achieved and learned in the last 12 months - and then, the newsletter will be back in January, after holidays.

This week, I’ll be sharing a small “Christmas gift”: my personal directory of AI and No-Code tools that I've discovered and used in 2023 (and before). It will not be an exhaustive, immense list of tools - but it will be very concrete. If you are passionate about AI and No-Code, I’m not sure you will find new tools here, but you will find tools I used and tested, with a short review of my experience, or tools that I already studied a bit and wants to try soon in the future.

Hopefully, this list will be useful for you all to reflect on how AI and No-Code could enter your daily work habits and improve your productivity!

Some thoughts about AI and No-Code

I’ve been interested in No-Code tools since 2021, and 2023 has been the year of AI, and it’s full of tools out there. No-Code tools are inevitably more mature, in general, since they have been around a lot longer - but AI tools have way more traction at the moment (and some tools are also both No-Code and AI).

I think that the time is mature for us, as Software Developers, to start adding some of those tools into our toolbox for our daily job, and that’s where this list comes from: my own experience in starting using these tools in the real world.

One of the things that astonishes me is that looks like AI tools have been accepted more by Developers than No-Code - I mean, AI is fascinating, especially for tech people like us, but No-Code is way more mature at the moment and offers solutions to simplify some architectural patterns.

This is one of the points I want to touch here: No-Code is cool, and has a lot of potential - give it a chance!

The second point is: be careful! Especially AI tools, but also No-Code tools, are still relatively young - make sure to a spike and/or POC to test it works as desired and monitor the tools to be sure that they can sustain your system and that you can trust them.

The third point: be open-minded! Some ideas to use such tools will be straightforward, but for others, you will need to be creative.

I think 2024 will be the year when such tools will become “common enough” in our systems and can help us speed up some of our implementations!

The list of tools

AI Tools

Tools I Use Often

• Grammarly: An AI-powered writing assistant that helps improve grammar and writing style - I have used it since 2021 and in the last year I got access to Business features thanks to my company: worth it! The effectiveness of Grammarly, at least in English, is amazing!

• Ideogram: An image generation AI, an alternative to Midjourney, DALL-E, etc. It is pretty simple to use via a simple browser UI, and generated images are pretty nice, especially for comics-stiles; it also produces written text well enough. I typically use it to generate the images for my newsletter and other type of content.

• ChatGPT / NotionAI: I mostly use these two to help me with the draft, outlines, and ideas for content creation. I think NotionAI is generally better in its outputs, at least for text content creation, but only when I can use my Notion Second Brain content as a reference. In other conditions, ChatGPT is more flexible and returns good text too.

• Quillbot: A powerful paraphrasing tool that uses AI to generate alternative suggestions for text: sometimes, I’m not sure that what I wrote in English is actually fluent to read, or just need some suggestions for synonyms to avoid repetitions, etc. When Grammarly is not enough, Quillbot is a great additional tool to get help on that! Can also be useful when you need to find a good name for a variable/class in programming, to look for alternatives.

Tools I've Used a Few Times

• GitHub Copilot: You all know this one! I will be honest: it’s not completely in my flow at the moment. I hate the definition on the website (“Your AI Pair Programmer” - please, pair programming is something else), but I can get over it :D I just have to find a way to use it better. But it’s powerful, and can speed up some coding stuff: I will increase usage for sure!

• Gummysearch: An AI analysis tool that leverages Reddit audience data to generate business ideas. It’s amazing the amount of data and information that Gummysearch can provide - some default audiences are offered from the tool, but you can try to create your own and generate a custom data fetch. Some info about the audience is behind a paywall, but if you are looking for niches and business ideas, this is a great tool!

• Founderpal: A marketing strategy generator powered by AI. You just describe your idea and you receive a user persona and suggestion for marketing that idea. As simple as this. Don’t expect a tailor-made marketing strategy in detail, but some actionable tips and initiatives you can put into practice, for sure!

Tools I Want to Test in the Future

• Video 2 shorts converter: A tool that converts long videos into short, engaging clips: I want to come back with podcasts and will publish them also in the video version, so the idea is to repurpose shorts from the podcast video, of course, in addition to dedicated shorts. I selected a group of three tools to test: Vizard, 2short, and Quickvid

• Rewind.ai: The promises of Rewind are amazing: Rewind runs in the background capturing your screen and audio, then compresses, transcribes, encrypts, and stores your data locally (so only you have access) and you can chat with him and ask questions about all that happened, like meeting notes, email drafts, etc. Something that might be worth trying!

• Browse.ai: An AI-powered tool that can extract data from a web page and put it in a spreadsheet. I have a couple of side projects where I would need such a tool to collect data from non-formal sources, and in general, it happens quite often that you need to collect data in a company so it’s a tool that can be useful to learn also for suggesting it when someone need to do something similar.

• Asknotion.app: An AI-based question-answering platform that integrates with Notion - the idea here is to connect this to my Second Brain databases on Notion to see what it allows me to do and if it’s more useful than Notion AI itself. If the questions are more free, it might be interesting!

• AI-TDD: An AI tool for Test-Driven Development - and here, I’m dreaming. What I want to do is try to practice doing TDD with me writing tests, and AI implementing and refactoring the code. The idea behind this is that I expect in the future AI could remove the need to maintain code from us - because it will be able to it by itself - but good Agile practices will always be useful to reduce risks, be sure code does what we need, release often, etc - and this could be the first step in that direction!

No-Code Tools

Tools I Use Often

• Substack: The platform I use to handle this newsletter - it’s easy to use, allows for premium subscription and other potential functionalities I might use in the future, and it’s continuously evolving.

• Notion: A versatile workspace tool that enables collaboration and organization. I use it for a multitude of stuff: my daily job Journal, my personal notes about all the learning content I study (from books to online courses, blog posts, podcasts, etc.), tracking my quarter/weekly objectives, organization of all related to Learn Agile Practices (newsletter content calendar, podcast content calendar, but also workshop content, etc). It’s amazing and easy to use, and it also has APIs, that can always become useful somehow.

• Carrd: A simple and intuitive website builder for creating landing pages and portfolios. It’s very basic and simple, with low pricing but with high value in return, I have my website built on top of it and also use it for landing pages and forms - I will use it for sure to launch my TDD Workshop next year!

• Bento.ai: A simple link in bio website builder, with a UX/UI that reminds me of Notion in some elements - I like simplicity and I used this for a basic link in bio for my social pages.

• Supabase: A backend-as-a-service tool based on a PostgreSQL database with a web UI interface to configure it and handle data, and automatic REST APIs exposed for each table in the DB. It’s amazing, I used it for some simple microservices in the past, especially for the read-side of a CQRS approach because the automatic APIs prevented the team from writing a lot of boilerplate code.

• Zapier: An automation platform that connects various apps and services - it has a lot of integration already existing and available, allowing you to connect popular tools without coding - but also allows you to create your own connector to connect your system to others.

Tools I've Used a Few Times

• Adalo: A no-code platform for building mobile and web apps - I helped my old CTO build a simple CRUD app for a non-profit association once, it worked well and was easy to set up and maintain.

• Webflow: A visual web design tool for creating responsive websites - I built a couple of websites for startups on this. If you only need a static website, that doesn’t integrate directly with an application, Webflow is pretty nice, and much more lightweight and simple to use than WordPress IMHO.

• Hasura: A GraphQL engine for building scalable and real-time applications - it can be connected to a database and then automatically expose the GraphQL to enable a client to access data, allowing also to set up permissions easily. This was the first tool I used with the approach described also for Supabase, to automate the read side of a CQRS infrastructure; compared to Supabase itself, Hasura can be used on a custom DB without requiring to use of a separate PostgreSQL DB.

Tools I Want to Test in the Future

• Retool: A no-code platform that enables to creation of a UI for a given REST/GraphQL API - I tested it for fun and I noticed it integrates very well, especially with GraphSQL, and can be a good option in the future to test for internal tools.

• Notion as CMS: Utilizing Notion as a Content Management System for Websites. I have at least two use cases in mind: first of all, actual website content handled via Notion (some tools already allow handling a newsletter, or a blog, using a Notion db as source for the content) - the second use case is an internal tool (as you can notice, automating an internal tool is one of my main ideas: the reason is that those tools typically burn a lot of time and money). Imagine using Notion as CMS for an e-commerce, or any other customer-facing tool where you want to give control to stakeholders over the control - instead of implementing a tool you might use Notion and then sync the data via the APIs.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Go Deeper 🔎

🤖 AI Tools Directories

• There’s an AI for that

• AI Tools Directory

• AllThingsAI

⚙️ No-Code Tools Directories

• No-Code MBA

• NoCodeList

• No-Code Forge

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome to the home of continuous improvement and learning for Software Developers.

📌 In case you missed it: in the last issue, I wrote a piece to describe the Walking Skeleton, one of the most underestimated Agile Practices: start small also on the architecture, but cover the entire architecture from the beginning - this way it will be easier to evolve it. In case you missed it, check it here.

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

Trunk-based development might increase burnout? 🔥 My thoughts on the 2023 State of DevOps Report 🤔

Introduction

Hello, developers! 🚀

The 2023 State of DevOps Report was released in October 2023, you can find it here: it’s the annual update to the research on which the book Accelerate was based on in 2018. Every year, the research continues and the update is released, but this time, for the first time (as I can remember, at least) a real concrete negative effect has been registered after one of the Agile Practices considered in the research - in particular, it’s Trunk-based development.

Let’s reflect on the research!

The 2023 State of DevOps Report

On the 18th of November, I attended the Italian Agile Days 2023 Conference in Milan as a speaker, at the Politecnico University; my talk was just right after the lunch break, and I talked about Continuous Integration and Trunk-based Development, how those two practices are related and which benefits they bring - the video is not available, but you can see the slide deck here.

During the Q&A session, one of the questions came from Ruggero:

What’s your opinion about the last State of DevOps Report, where it emerges an increase of burnout due to Trunk-based Development?

At that point, I hadn’t read the report yet, only a quick recap article that didn’t highlight much of this burnout topic - so I was a bit surprised, and I responded that it’s hard to have an opinion on this without having more context. For example, if the practice is forced on the team, or it’s not supported by proper training, I can imagine that at least in the first weeks it can be an overhead for people used to long-living branches. Still, my experience is similar to Ruggero’s: CI and TBD make life easier, and I’ve seen this for both average and above-average skilled developers!

So, I left the conference with this question in mind and decided to look for the complete report, and for more complete articles about it, to see what it states and reflect on it - this article is the sum of my thoughts!

Some key insights from the report

The article from the DORA team highlights 5 key insights:

1. A healthy culture matters: teams with generative cultures have 30% higher organizational performance

2. User in mind: teams that focus on the user have 40% higher organizational performance

3. Documentation has an impact: high-quality documentation leads to 25% higher team performance

4. Work distribution is not fair: women and underrepresented people have higher levels of burnout

5. Cloud used effectively: leveraging the characteristics of the cloud, like rapid elasticity and on-demand self-service, teams can get the most value out of the cloud: this flexibility leads to 30% higher organizational performance

The first thing I noticed was that the recap/announce article from the DORA team does not emphasize much about burnout increase related to TBD. At this point, without reading the report yet, I had 2 hypotheses: either there is something more in the report that makes them not give that much weight to that, or they are trying to ignore it for now to avoid controversy.

While the second is still an option (it can even be for a good reason: it’s the first time that shows up, so we still need some confirmation before actually worrying about it), I couldn’t avoid approaching the report hoping to find something supporting the first option: “there must be something more”, I thought.

And finally, I started reading it.

Burnout can increase with TBD?

The technical capabilities considered and analyzed in the report evolve year after year, so it’s important to consider that these are the 5 technical capabilities considered this year:

• AI

• Trunk-Based Development

• Loosely coupled architecture

• Continuous Integration

• Rapid code review

As always, the report considers 2 types of impacts: performance measures (team, organizational, software delivery, and operational performances) and indicators of people's well-being (burnout, productivity, job satisfaction).

Focusing on Continuous Integration and Trunk-Based Development here, the impact on performance measures overall is quite good, as always: both practices showed minor increases in team, organizational, and software delivery performances, with a minor decrease in operational performances for TBD.

On the other hand, looking at people's well-being’s indicators, it looks like there is no effect directly from this two practices in most cases, but with minor increase in job satisfaction thanks to CI, and a substantial increase on burnout because of TBD.

And here we are! Let’s deep dive into this part of the Report to find out something more: we have two sections to discuss, the first one being this data with some additional info and comments, while the second one being a note on the benefits of Continuous Delivery from Dave Farley.

Before looking at the conclusions and answers we can take from the report, one side note from me: I’m not sure that those practices should actually be considered separated. I mean, CI embeds TBD - it is the actual topic of my talk at IAD 2023 - so focusing on TBD means focusing on 1/6 of CI. As always, discover more about this and my other personal thoughts in the next section, Dan’s take.

Back to the report: about performance measures, no particular comments worth highlighting here - they basically consider it all positive. To be honest, they treat as pretty positive also the people's well-being’s indicators - quoting the report:

Additionally, these capabilities and processes don’t show a detrimental impact on the well-being of the individuals doing the work. In fact, most of these predict improvements to the individual’s well-being.

A lot more focus is on highlighting how much all the indicators increase positively than on asking why one decreased - I’m not sure if it’s correct from the scientific approach point of view, but for sure it looks a bit surprising for me.

Even Dave Farley looks more surprised from the impact on performance measures (positive, but not as much as he expected) than from the people side:

I am somewhat surprised that continuous integration (CI) and trunk-based development didn’t have a bigger impact on software delivery performance.

And finally, two new metrics are added here: stability (change failure rate and failed deployment recovery time) for quality and throughput (change lead time and deployment frequency) for fast feedback and problem detection.

But most of all, the concept of mediators is introduced: CD, for example, is a mediator of many technical capabilities (including CI and TBD), meaning that those capabilities works because they create an environment that enabled CD.

Basically, Farley highlight something similar to my question above: we cannot just consider those capabilities as separated, they are connected to each other - one might be enabler for the other, and so on.

So, when we read at this data where TBD seems to be a (rather small) danger to burnout, we should consider that, for example, code review speed substantially decrease the burnout - and what’s a best way to reduce code review time than reducing the size of the review via TBD? 😉

I will share my thoughts in the next section, as always - but let me know what do you think by replying to this email or commenting the LinkedIn/Twitter post where I shared it!

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

I have to admit that the question at the conference made me panic a bit: Accelerate, the research behind that book, and the yearly updates to the research are one of the best tool we can use to support and proof the importance of the Agile Practices for a business, and while it is totally correct (and to be appreciated) that elements against the ideas are highlighted - if that happens, we need to be very very effective in communicating correctly because it’s already hard enough to make people understand the importance of this kind of technical excellence.

I really wanted to find something that justified that outcome, and at first I was also disappointed that the research never discuss the point directly - but then, I thought: “there must be a reason”.

I mean, is not that I want to justify something just because it’s coherent to my beliefs, but the entire research over the years is based on questioning our beliefs and understand their impact in a transparent way - I really couldn’t believe that they wouldn’t be transparent about that.

Luckily, I was right - even if it’s not addressed directly (they never say “TBD seems to lead to an increase in burnout, but…”) it is definitely addressed in the considerations an thoughts about the overall outcomes.

The main point, which is both my initial thought and also what they highlight multiple times in the report, is that even if they treat the technical capabilities separated for research purposes, they should always be seen as strictly correlated: if you think about it, 4 out of 5 technical capabilities examined (AI excluded) are needed to enable Continuous Deployment.

Quoting Dave Farley, page 24 of the report:

CD—the ability to release changes of all kinds on demand quickly, safely, and sustainably—is a substantial mediator of many technical capabilities.

[…]

The practice of CD, in turn, provides the mechanism through which these capabilities can predict stronger software delivery performance.

[…]

For example, how can we achieve high scores on Throughput if our code doesn’t integrate, and how can we be sure that our Stability is high if we haven’t checked it? For me, CI is how we know these things, and so it’s a key mediator of software delivery performance.

Look at the tables from the report:

There are some points we can agree on:

• 72% of the impact is positive (4 decreases and 6 no effects on a total of 35)

• Except for AI, the other 4 capabilities are strictly related to each other

• Except for AI, the other 4 capabilities are together enabling even more technical capabilities and practices

I will use an example to express my feelings about all this: we can say that the impact on burnout of the 4 capabilities is a substantial decrease (no effect + substantial decrease + substantial decrease + substantial increase), and the 2 capabilities impacting positively are a faster code review speed and a loosely coupled architecture.

The things is: how do you increase code review speed? With TBD, because you reduce the batch work size, meaning the size of the review, making it easier and faster to both find a time span to perform the review, and also to do the review itself: if every team member creates daily (or shorter) PRs, they will more easily find the time for performing the review without too many interrupts, and review itself will be faster.

At the same time, it’s almost impossibile to achieve CI if we don’t have loosely-coupled teams, splitted by domains and without depending to each other for PRs and releases - and this open the chances to achieve a loosely-coupled architecture too.

As you can see, it’s all connected, so here is my final thought: we cannot just think to this results looking at the specific item, same as we cannot think about team performance by looking at the performances of a single developer - we need to think about the whole system, and in this case the whole research, the entire group of practices considered and their impact with each other.

But, I think we also need to face this in a correct way, and it looks that me and Dave agree also on this (see quote below): this is, in any case, an interesting and intriguing thing to keep a look at, and we will probably discover more in the next year State of DevOps Report!

I mean: we always keep “uncovering better ways of developing software”, right? 😉

Go Deeper 🔎

📚 Books

• Accelerate - How can we apply technology to drive business value? This book is the first production of the research that is now yearly updates with the State of DevOps Report.

• Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation - This groundbreaking new book sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users.

📩 Newsletter issues

• DORA Metrics: We’ve Been Using Them Wrong [Dev Interrupted]

• Continuous Delivery: Progress is the foundation of happiness [Snackable CTO]

• Why Are Teams So Slow to Adopt Simple Continuous Delivery? [Crafting Tech Teams]

🎙️ Podcast episodes

• Dora Metrics [The Continuous Delivery podcast]

• How to measure and improve developer productivity [Lenny’s podcast]

📄 The Status of DevOps Report 2023

• Recap article (you can also download the report from there!)

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome to the home of continuous improvement and learning for Software Developers.

📌 In case you missed it: in the last two issues, I wrote a 2-part fake trial where I tried my best to prosecute TDD, supporting all the critics that are typically moved against it - and then trying to defend it, supporting both points of view with the most concrete approach possible. In case you missed it, check the first part here, and the second part here.

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

First Steps in Code: The Significance of a Walking Skeleton in New Projects 🚀🪴

Introduction

Hello, fellow developers! 🚀

To introduce the idea of the Walking Skeleton practice, let me describe an example: a new project starts, we work on the features for months and it all works locally, and it’s complex enough to include a database, an admin dashboard, a queue system for async processing and a Redis instance for cache; then, we need to build the architecture to deploy on a test environment: here we will have to understand how to set all that stuff up on a test environment, in a cost-effective way, and after some tests, we will probably need to fix something on both code and architecture; finally, we will need to move to production: typically, our choices here will change because “it’s production“ and we will have to rediscover and fix some issues, probably old and new ones, all together. We were basically done with development, but architecture and release for both test and production took weeks, mostly because we had to face all those issues together.

If this situation is familiar in some way, you will easily understand what benefits can bring the practice of walking skeleton: let's get started!

Start small, also in the architecture

Alistair Cockburn defined the Walking Skeleton practice as:

a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

A similar concept called “Tracer Bullets” was introduced in The Pragmatic Programmer.

In simple words, when you start a project with a walking skeleton, you first build a minimal functionality (as simple as a “Hello world” page or API) and then release it to the test and production environments.

By doing this, you start building all the pieces that together will create your system, each in its own easier and smaller version possible; for example, every automation and tool you need should be in place, including:

• the automated pipeline to build the app, execute tests, trigger the deployment, etc

• the logging, monitoring, and alerting systems to allow for instant alerts of errors and easy investigation

And, of course, you will also need the servers to deploy the code, whether it is in the cloud or not: you will have the simplest version of your system and architecture, while the features are still zero.

This practice aims to broaden the baby steps and YAGNI principles to include the entire system, and not only the codebase: by doing this, we are reducing the chances of issues and mistakes happening by splitting the complexity of building our architecture through time instead of facing it all together just before releasing, and we will also be sure that all we add to our system is because we need it, when we need it.

Moving on with the example, we will build only what is required, which is the minimum stuff we should all have in production:

• the automated pipeline

• a log system

• a monitoring system

• and alerting system

• a server for test env

• a server for production env

Since we want to follow YAGNI and baby steps, we also don’t want to build the “ultimate” version of any of those: for example, the pipeline will be minimal (build, execute tests, deploy) and we will postpone decisions such as which static analysis tool to use; the alerting system might start as an email and evolve to Slack or any different channel in the future; the monitoring system might only show minimal data required to check if there are issues; the servers will likely have very little memory and CPU power, and so on.

Here is a sample list of what we will not have at first, even if we will likely need them in the future:

• a database, or any other persistence layer

• a way to handle environment variables

• a way to handle secrets

• a Redis cache instance

After being done with the Walking skeleton, we will start working on the first feature - and as soon as the need for one of these pieces shows up, we will add it to our infrastructure.

An underestimated practice

Every time we want to learn a practice, we should strive to understand why that practice is important from a technical and business perspective, and the walking skeleton makes no exception.

As already mentioned, the two main principles behind it are:

• Baby steps: In the same way as working with short branches it’s easier than using long-living feature branches or using TDD to get feedback every minute on our code makes it super fast to fix any mistakes we make, adding pieces to the system one by one will drastically reduce the complexity compared to putting all pieces together at once/

• YAGNI: “You Aren’t Going to Need It” - a very well-known principle in software development, typically used to refer to the idea of not adding pieces of code to generalize or expand a feature just because “you never know, we might need it in the future”; instead, stick to what you need today, and add new pieces when the need appears - here, we want to apply the same principle to the entire system: for example, why adding a database while you don’t have any table yet? When the need to persist some data comes, for example, you might even discover you need a no-SQL solution for that specific use case. It’s not only to wait to split complexity along the way but also to ensure that you decide in the last moment possible to ensure it’s the best decision possible.

In addition to these principles, the Walking skeleton shares a target with every other agile practice: reducing risks. According to Hofstadter’s Law:

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Making changes to architecture becomes more difficult and expensive over time, as it ages and grows in size. As in many other agile practices, we want to identify errors as soon as possible. This technique provides us with a short feedback loop, allowing us to adjust and work iteratively as needed to fulfill the business' needs. Assumptions about the architecture are validated very early and any error is discovered early in the implementation process, causing an easier evolution of it.

In the end, the Walking Skeleton is a practice to validate the architecture and get early feedback so that it can be improved. It’s fundamental that you don’t write the first acceptance test until the walking skeleton is deployed to production, possibly behind a feature flag or just hidden from the outside world if required, because you want to exercise your deployment and build scripts from the beginning to discover as many potential problems as you can as early as possible.

I know what you are thinking: but Dan, this means we have a test and production environment since day 1 that we have to pay for!

Short answer: yes, and you will not regret it.

Long answer: the additional cost of having a test and production environment from scratch should be very little, considering how simple the system will be at the beginning; in most cases, there will probably be a free or very cheap option in any hosting service you are using. And this time should not be long anyway, because you are releasing the first version, which should be an MVP. You don’t expect to work 6 months before reaching the first release, right? 😉

Let me know if you already use this practice and what you think about it!

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

The reason why Agile principles, methodologies, and practices changed my career is because they brought answers to questions that tormented me since my day 1 as Software Developer:

• How is it possible that there is no way to ensure I don’t break my previous code? Automated tests

• How is it possible that there is no way to make coding easier and safer? TDD

• How is it possible that there is no way to notice errors in production? Monitoring & Alerting

Walking Skeleton practice had the same impact: how is it possible that there is no way to avoid releasing everything at once in the end? The walking skeleton (and evolutionary architecture principle) is the answer to this question at an architecture/entire system level, the same way as Continuous Integration/Trunk-Based Development is the answer at the code level.

The first time I worked to a project where the Senior leading the team brought this technique up, it was amazing to see the impact. Setting up pipelines, monitoring, alerting, logging, and everything else all at once when the features are done and ready for tests - and then repeating everything all at once to setup production just before the release - has always been a nightmare experience.

The very long TODO list in the backlog united to the stress of the release coming closer is a devil mixup that makes issues very very likely. By creating a Walking Skeleton, we create the simplest version possible of each of those elements, and then evolve them together with code and requirements: in the same way that CI avoids big merge conflicts and time-consuming async Pull Requests on big changes, the Walking Skeleton will avoid accumulating all the work related to the setup the system and architecture, splitting it along the way, making it easier to handle the (small) changes.

Once you start working in baby steps, iterative way you find it useful in any circumstance, even in your personal life, so being able to approach the architecture and system the same way I approach coding and development is great!

Typically, I consider the Walking skeleton of a new service once I have:

• Local environment setup running under Docker + Docker Compose, including both features and tests (I most often build APIs, so I typically start with a GET /hello-world API and its test)

• Setup of the logging system (depending on the language and framework) to print logs in standard format (typically JSON) via standard output

• Makefile to create the catalog of repetitive useful commands to be used locally during development

• Readme file with basic stuff like info about the project, prerequisites, and how to set up and run locally

• Pipelines (typically via GitHub Actions) to build and test the service and then release it on test at every push on the master branch, and on production at every tag

Test and production environments are born identical (and should always remain such):

• A server somewhere to release the Docker image of the application

• A login system that gets the standard output and allows to easily search and read logs

• A monitoring system that notices any error happening (basic example: 500 HTTP responses of APIs)

• An alerting system that emails the team when an error happens (at first, it can even email me at the first error immediately)

One last tip from my experience: when I am in a micro-service context and my team creates new services very often, I typically suggest creating a template repository with the walking skeleton, so that when you need a new one you can start from there and speed up the code part of the skeleton, focusing only on the architecture one - if you add infrastructure as a code to this example, you can basically automate a good part of walking skeleton.

Go Deeper 🔎

📚 Books

• Growing Object-Oriented Software, Guided by Tests - This book talks about a lot of great practices, and chapter 10 is dedicated to Walking Skeleton iself.

• The Pragmatic Programmer - In this book, the Walking Skeleton practice is referenced as “Tracer Bullets”, and the principles are mostly the same; in addition, the book is filled of useful tips for being a good and professional developer

📩 Newsletter issues

• How to start a new project ? What is walking skeleton ? [Tony’s Substack by Tonydev]

• Creating the walking skeleton - Part 1 and Part 2 [Sivu Writes Software by Sivu Makhonco]

📄 Blog posts

• Start your Project with a Walking skeleton

• The Benefits of Using Walking Skeleton Approach in Software Development

• Using Walking Skeleton Approach in Software Development

🎙️ Podcast episodes

• Iteration 0: Walking Skeleton [The Competitive Advantage podcast]

• Creating a Walking Skeleton [InfoQ podcast]

🎉 Milestones Reached 🎉

🎉 Hey, developers! Welcome to the home of continuous improvement and learning for Software Developers.

📌 In case you missed it: this is the second part of an imaginary trial: we are trying our best to prosecute TDD, supporting all the critics that are typically moved against it - and then trying to defend it, supporting both points of view with the most concrete approach possible. In case you missed it, check our archive for the first part.

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

🧑🏻‍⚖️ Putting Test-Driven Development under Trial: Could the Critics Be Right? 😳 Part 2

Introduction

Sorry, a wrong email started yesterday. This is the correct email with the complete introduction. Sometimes, we just make a mistake - sorry again. Enjoy the issue! 💪🏻

Few practices in software development have sparked as much debate and controversy as test-driven development (TDD). Advocates think it's a panacea for writing clean, manageable code, while critics argue it's a time-consuming and unneeded burden. Last week, we started a trial on TDD. Imagine a courtroom in which the prosecution throws charges and the defense rallies to demonstrate that those charges are wrong.

I collected all the critics I found online about TDD, and we are giving all those critics the benefit of the doubt, trying to go very deep into understanding the cons that they typically suggest and to support their ideas - then, we will also try to demystify it. In the end, I will share with you what thoughts I had after all this work.

So grab your gavels and robes, for we're about to embark on the second part of the TDD trial of the century! 🏛️👩‍💻👨‍💻

k to the Trial 👇

Here is the updated list of the 8 most common criticisms that people throw against TDD - a list I collected by searching online and from past experiences and chats, and we already discussed the first 4 points in the first part last week:

1. Time-Consuming

2. Too much overhead

3. Focus on Testing, Not Design

4. Inflexibility

5. Over-testing

6. Difficult to Learn

7. False Sense of Security

8. Not Suitable for All Projects

Today we will continue our ping-pong challenge between the prosecution and defense of TDD, completing the list with the last 4 points and then going straight to the conclusions.

TDD cause over-testing

Prosecution

Ladies and gentlemen of the jury, let's restart this trial by delving into another pressing issue surrounding Test-Driven Development (TDD). Detractors claim that TDD, in its zealous pursuit of robust code, can inadvertently lead to over-testing. The concern is that developers, driven by the TDD approach, might find themselves entangled in an exhaustive quest to cover every conceivable edge case.

This meticulous testing, as critics argue, can be a time-consuming and unnecessary endeavor. Picture this: developers navigating a labyrinth of test scenarios, trying to account for every possible nuance. We must ponder whether this exhaustive approach to testing is truly warranted or if it's an undue burden on the development process. As we proceed, we'll unveil the intricacies of this claim and explore whether TDD's emphasis on comprehensive testing is a necessary virtue or an onerous vice.

Defense

Your honor, and ladies and gentlemen of the jury, please excuse me but I’ll have to be repetitive on this one - because once again, the prosecution against TDD has no concrete pieces of evidence.

As I mentioned last time, Kent Beck shows us how the same problem caused him to write 6 tests, while another developer wrote 65. Quoting the book:

You will have to decide, from experience and reflection, about how many tests you want to write.

TDD's view of testing is pragmatic: tests are a means to an end, the end being “code in which we have great confidence”. The number of tests we decide to write will depend on the confidence we have in the problem and a possible solution.

There is another thing that most often is not considered: tests in TDD lead you to a solution, but then you only want to keep with you the tests you need to feel safe when that code changes. It’s not uncommon that once your work is done, you might consider throwing away some of the tests that you used - because they already fulfilled their purpose in driving you through design decisions but they don’t add any confidence when changing the code.

TDD is hard to learn

Prosecution

There is another contention against Test-Driven Development (TDD) that we want to highlight today. Critics vehemently assert that TDD, with all its purported benefits, presents an insurmountable challenge for developers new to the practice. The crux of the matter is the formidable learning curve associated with TDD, which, according to the prosecution's argument, may serve as a deterrent to its widespread adoption.

The prosecution contends that TDD is not just about mastering the art of testing; it entails delving into the intricate principles that underpin effective test-driven development. This dual challenge, critics argue, places an undue burden on developers, especially those navigating the early stages of their TDD journey.

Defense

There are two sides to the medal when discussing the learning curve of TDD: first of all, it requires a shift in the way we think about problem-solving. Most of us learned to develop software in a specific way: code a solution, then test it. TDD requires a shift where you think about your tests before writing the actual code - and not only at a high level but also for every step we make in coding the solution.

The second point is that TDD also brings the approach of small steps and continuous design feedback thanks to the TDD cycle and the fact that we execute the test suite every minute; we are all typically so used to working with long-living branches and getting feedback only after a lot of time - and even if that late feedback is often uncomfortable, a lot of people think it is inevitable.

To learn TDD, you need an Agile mindset: you need to embrace change to accept that there might be another way to do things, maybe even better ways.

TDD is a way to ensure that you produce “clean code that works”, having a simple way to avoid bugs and defects or recognize them very early when they happen; it’s a way of doing one thing at a time, to avoid being overwhelmed by a lot of ideas when coding; it’s a way to improve the design one small step at a time, without getting stuck in implementing a certain design patterns because the step was too big.

I’ve never seen someone having a great level of confidence in those without TDD, and even if you can do it, ask yourself how much energy it requires you - with TDD, it’s all included.

TDD gives a false sense of security

Prosecution

We are not done yet, and now let's delve into another critical assertion against Test-Driven Development (TDD). Detractors argue that the pursuit of extensive test coverage, a hallmark of TDD, might inadvertently foster a false sense of security among developers. The crux of this contention is that developers, ensconced in a cocoon of extensive testing, might be led to believe that their code is impervious to bugs.

The prosecution posits that an overemphasis on test coverage could be a double-edged sword, providing a deceptive assurance that the codebase is devoid of defects. As we scrutinize this claim, we'll explore whether the purported sense of security induced by comprehensive testing is a commendable outcome or a perilous illusion that detracts from the rigor of software development.

Defense

No one advocating TDD will ever tell you that if you do TDD you will never have defects, bugs, or any problem. It would be just false, anyway.

TDD is a way to minimize unplanned work, which includes bugs and defects for sure. Minimize doesn’t mean avoiding completely - you can always make mistakes, for sure, even if TDD minimizes the fact that a mistake is integrated into the main branch and reaches production or even staging. But it can happen because we are humans.

Doing TDD doesn’t change the fact that you should have a good monitoring and alerting system - or more in general, a way to notice problems immediately when they happen, a good rollback strategy if required, and also working in Continuous Integration releasing a small batch of work every day so that even if an issue shows up in production the change will be very little and fixing it will be very fast.

TDD is not a replacement for that, for sure.

TDD is not suitable for all projects

Prosecution

And finally, your honor, let us now address the last critical viewpoint we want to level against Test-Driven Development (TDD). We want to contend that TDD may not be the optimal strategy for projects characterized by swiftly evolving requirements or those in the throes of highly experimental development.

The prosecution submits that TDD's insistence on defining tests before actual code might pose a challenge in the context of projects where requirements are in constant flux. We shall examine this claim closely, scrutinizing whether the rigidity of TDD aligns with the demands of dynamic and experimental development environments or if it becomes a hindrance in such scenarios.

Defense

Well, your honor, here we have something that can be partially true, but… the reasons why this can be true are completely different from what the prosecution suggested.

Is TDD suitable for all projects? Yes, it is. It’s also suitable for startups and small businesses because it will cost less money spent on developing software, most often because of less time invested in giving the feature to customers and reduced unplanned work. “Accelerate” (the book) proved this in the research it is based on.

Is TDD suitable for any coding situation? Maybe not, as always there are special cases.

For example, when you are doing a spike or some thinking around code, you might want to avoid tests, at least at the beginning, because you are just looking around and you don’t have any clear questions to respond to. Once you have it, Test-First is a good way to formalize it, for example, but you might decide to follow TDD strictly or not depending on the situation.

Well, this fake trial finally ended - and it was a good, fun exercise to try to collect all the concrete ideas against TDD and also try to debunk them afterward.

As you all know, I love Agile Practices, but I also want to be sure that it doesn’t become a dogma where I’m not able to recognize the reasons why it is good anymore - so I feel that sometimes trying to discuss against it, even internally, is a good idea.

What do you think? Reply to the email to let me know what you think about TDD and if you practice or are interested in learning it!

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

I will not add much today, because the target of the trial is to try to be non-opinionated most of the time, but hey - this is my personal take zone, so it’s opinionated by definition.

First of all, I want to say that it was really fun to build this fake trial: I used Chat GPT to help me write the prosecution part in an attorney language, and after a couple of prompts tests, I was able to get a good enough result, hopefully!

As always, collecting points against something I love is a great exercise: it makes not only reflect on some elements that are actual criticism, but also reminds me of why such practices are great, which is always important to avoid them becoming a blind dogma.

Here are some reflections I made in the process:

• A lot of people consider TDD time consuming, while today I’m a lot slower when I don’t write tests before; this makes me reflect a lot on the fact that a lot of people don’t learn enough about something before using it in the real world, and this is bad - whatever it is that “something”. We should consider writing software for production more like a match for a professional sport: it’s our performance, and at that moment we have to win in any way (in our case, getting the result with the lowest cost possible) - it is not the moment to “try something new I never tried before”, for that you should the training to build the confidence you need to then use it during the real performance.

• Resistance to change is a real thing for human beings, and it’s hard to fight. But since I started to talk about TDD around, and hosting workshop, I realized that a lot of people just need a bit of support - they start learning TDD but they are not pushed by the environment in growing into that direction, and then it requires a huge willing power to keep going on; if you want to learn TDD and you are having hard times, before giving up, find a mentor!

• The “there is no silver bullet” and “there is always a trade-off” are very useful quotes, but sometimes we use them to hide ourselves from the truth. I want to be completely honest: I still haven’t found any actual cons to TDD. I keep looking for it because I want to be a critic to grow even more, but I can’t find it. I’ve never seen someone doing TDD and regretting it or highlighting limits - I’ve always seen people who find it hard and then start arguing against it. TDD produces better software, it’s a fact.

Go Deeper 🔎

📚 Books

• Test-Driven Development: An Empirical Evaluation of Agile Practice - this book includes the results of three different experiments, including concrete examples of how to conduct statistical analysis, using as evaluation indicators the number of acceptance tests passed (overall and per hour) and design complexity metrics.

• Test Driven Development: By Example - the original book from Kent Beck that explains TDD, with examples, and also explain some pitfalls for experts practitioners

• Learning Test-Driven Development - Author Saleem Siddiqui shows you how to tackle domain complexity using a unit test-driven approach. TDD partitions requirements into small, implementable features, enabling you to solve problems irrespective of the languages and frameworks you use.

• Growing Object-Oriented Software, Guided by Tests - Implementing TDD effectively: creating cleaner, more expressive, more sustainable code using tests.

📩 Newsletter issues

• Everything I know about introducing TDD in an org [The Engineering Organisation by svs]

• Introduction to Predictive TDD [Make Your Code More Testable by Ted M. Young]

• Use Test-driven Development to Retain Modularity [Crafting Tech Teams by Denis Čahuk]

📄 Blog posts

• The real reason why you don’t like TDD

• How to evaluate Test Driven Development (TDD) Research

• The evidence is in: TDD works

• The Evidence For TDD

• Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software

• Test-Driven Development (TDD) and Why People Get it Wrong

• Why Test-Driven Development After All?

• Measuring TDD effectiveness

• How to Measure the ROI of BDD and TDD

🎙️ Podcast episodes

• TDD for today [Thoughtworks Technology podcast]

• Unit Testing With Test Driven Development [Complete Developer podcast]

• TDD with Ian Cooper [The Unhandled Exception podcast]

👨🏻‍🏫 Online courses

• Test-driven Development: CodeMash [Pluralsight]

• Introduction to Test Driven Development (TDD) [Coursera]

• TestDriven.io [a platform dedicated to TDD courses]

• TDD micro-learning - Our micro-learning courses catalog offers, among the others, a path dedicated to TDD: learn the core concepts at your own pace in an interactive learning experience

🕵️‍♀️ Others

➡️ How effective is Test-Driven Development - a research written by the University of Oulu, Carnegie Mellon University and Fraunhofer Center for Experimental Software Engineering

➡️ Quora post from J.B.Rainsberger about TDD effectiveness

🎉 Milestones Reached 🎉

🎉 Hey, developers! The biggest news of the week is that my first free Workshop, a 4-hour deep-dive into TDD basics and OOP misconceptions, took place last Saturday - and it was amazing. Stay connected because I will repeat some of those for sure at the beginning of 2024. Also, welcome 2 new subscribers that allow us to reach 46 members!!

📌 In case you missed it: two weeks ago, I talked about documentation in Agile, to try to remove some fog from some misconceptions about it! If you haven't already, make sure to take a read at it here and let me know what you think! 💪

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

🧑🏻‍⚖️ Putting Test-Driven Development under Trial: Could the Critics Be Right? 😳 Part 1

Introduction

Few practices in software development have sparked as much debate and controversy as test-driven development (TDD). Advocates think it's a panacea for writing clean, manageable code, while critics argue it's a time-consuming and unneeded burden. Today, we're putting TDD to the trial. Imagine a courtroom in which the prosecution throws charges and the defense rallies to demonstrate that those charges are wrong.

I collected all the critics I found online about TDD, and we will give all those critics the benefit of the doubt, trying to go very deep into understanding the cons that they typically suggest and to support their ideas - then, we will also try to demystify it. In the end, I will share with you what thoughts I had after all this work.

So grab your gavels and robes, for we're about to embark on the TDD trial of the century! 🏛️👩‍💻👨‍💻

Test-Driven Development on Trial 👆

Setting up the stage for the trial, as a (very bad) prosecution attorney, I was able to collect the 8 most common criticisms that people throw against TDD:

1. Time-Consuming

2. Too much overhead

3. Focus on Testing, Not Design

4. Inflexibility

5. Over-testing

6. Difficult to Learn

7. False Sense of Security

8. Not Suitable for All Projects

We will deep dive into each of those, in a ping pong challenge between prosecution and defense of TDD - the first 4 points will be in this week's newsletter, and then the 2nd part will come next week.

Let’s see which criticism is concrete and which is not, and how concrete and real those problems are raised by skeptics.

TDD is time-consuming

Prosecution

Ladies and gentlemen of the jury, it's essential to acknowledge that Test-Driven Development consumes an exorbitant amount of time. The reason is that TDD necessitates developers to compose tests before crafting the actual code, and this supplementary step serves only to extend the already arduous development timeline. TDD's insistence on creating tests prior to developing the actual code is an irksome and time-consuming ritual.

To elucidate further, allow me to emphasize the problems with TDD's initial phase, where the developer is burdened with the task of devising test cases. This detracts significantly from the rapid inception of the code, leading to longer project timelines. In fact, the documentation-intensive nature of TDD often exacerbates the already onerous demands of software development, resulting in an unwarranted delay in reaching the final product.

What we want to point out and make very clear here, your honor, is that TDD increase time for development, making the life a lot harder - and while we cannot prove that there might be a gain of time on the long run, we can definitely see we are slower in the immediate - and that is not good for business.

Defense

Honorable people of the jury, we vehemently refute this accusation: claiming that Test-Driven Development is time-consuming is something inaccurate that starts from some bad habits about learning and applying a new practice.

What we want to say is that for any new practices we want to learn and apply, we cannot start applying them on the job - we should invest time in learning via exercises and training, starting from trivia software exercises and then moving to more complex ones. If you start doing TDD and try to apply it while still learning and not being confident enough, of course, you will be a lot slower than usual. But this is an unsafe way of approaching new methodologies or technologies on the job, and it’s also disrespectful of the money the company pays us.

The reference here is professional sport: if you want to be able to apply good techniques during the match, where points are at stake and there is pressure, you must work hard first to excel in those practices during training, where you have no pressure and all the time needed for learning. Developing a feature for software that is (supposed to) make money, it’s our performance moment, it’s like we are in the match - there is pressure due to money and time, and that is normal, so you cannot use a practice/methodology/technology you are not confident enough, and you should build that confidence before via training.

And remember: training is a developer's responsibility, not the company’s: “company doesn’t give me time for training” is just an excuse, the responsibility for the quality of our work and our learning is ourselves.

TDD causes too much overhead

Prosecution

The next problematic point we want to highlight about TDD is that the testing code creates an overhead that complicates projects. One of the more troublesome aspects of TDD, as our esteemed critics contend, is the unwarranted overhead it introduces to software projects. This weighty accusation concerns the task of maintaining the testing code alongside the production code, which, according to the prosecution's perspective, considerably exacerbates the complexities of project management.

Now, please indulge me as we delve into the nitty-gritty of this allegation. Our critics astutely point out that TDD's unwavering emphasis on creating tests in tandem with the production code results in an inherent conundrum. As developers, we find ourselves in the unenviable position of maintaining two parallel sets of code - the production code itself and the code responsible for testing it.

This approach adds layers of intricacy to the project. This situation isn't merely an issue of maintaining an additional set of files; it involves ensuring that the testing code is in harmony with the production code. In our experience, such meticulous synchronization introduces confusion and can escalate into an administrative nightmare.

The stark reality is that the act of maintaining these test codes often leads to a decline in overall project manageability. We contend that this complication is just one of many signs that TDD is a practice far too cumbersome for today's fast-paced software development landscape.

Defense

First of all, your honor, I want to point out that is not merely about TDD, it’s a general attack on having automated tests in our codebase - which is even worse, probably, but also easier to defend.

The moment you start wondering how to make software development better and to have a better life at work daily, you start realizing that there is typically a lot of time wasted in unplanned work: bugs, defects, issues in production, and any other kind of activities that you cannot plan because it’s unexpected. Agile, XP, and Lean all agree that we should strive to reduce the time we spend in unplanned work to the minimum possible (around 20% of the time for high-performance teams, according to the research in the “Accelerate” book, against 27% invested by low-performance teams).

Writing and maintaining an automated test suite is a minimal investment that pays off by enhancing code quality, reducing defects, and increasing the maintainability of the code itself - meaning it reduces unplanned work in the future. TDD can reduce that even more, to be honest, because it ensures a couple of additional points:

• we are sure all the code is covered by tests without any additional effort

• you will write only the minimum code required for your current needs, meaning the YAGNI principle will be respected and you will have to maintain the less code possible

• big complex problems/features will not keep you stuck because you don’t need to overthink the entire design beforehand - you can just understand how to start and have a generic understanding, and tests will drive you to the solution

So we can say with absolute certainty that having an automated tests suite is very very helpful, and an investment that is worth doing - and TDD raises even more of that value.

TDD focuses on testing, not design

Prosecution

I'd like to draw your attention to yet another critical viewpoint, one that questions whether Test-Driven Development (TDD) leads us down a path of good design, as its proponents claim. Our esteemed critics argue that TDD's singular emphasis on testing overshadows the importance of promoting well-crafted software, and they propose that it often steers developers toward writing code primarily to fulfill test cases, rather than to foster sound design principles.

This critique, ladies and gentlemen, underscores a fundamental issue with TDD. The practice may encourage a myopic focus on satisfying test conditions rather than nurturing the kind of software that stands the test of time. Instead of nurturing the growth of elegant, maintainable, and efficient code, TDD, according to our critics, may drive developers to prioritize passing tests at the expense of the software's overall quality.

These criticisms, as unpalatable as they may be to some, should give us pause. We are left to ponder whether TDD is truly a beacon of good design or, as our critics assert, a practice that might inadvertently pave the way for poorly designed software. The prosecution contends that this is a matter we cannot afford to take lightly and warrants a closer examination of TDD's value in contemporary software development.

Defense

There are two questions we want to start our response from, to demonstrate that this accusation is completely without basis and concreteness.

The first question is: are you sure that it is bad to focus primarily on passing the tests? As the Agile Manifesto states, the first measure of progress is “working software” - and passing those tests means our software is working, so it is for sure something to celebrate and be happy about.

But the second question will add light also on the first one: are you sure that TDD emphasizes passing tests instead of good design? I think that the name here is probably causing some misunderstanding.

Let me explain: TDD means Test-Driven Development. Development is the process where we add functionalities to a software, and while we do that we also decide the design of the software to achieve that purpose. TDD means that you develop software by letting the tests drive this process, and TDD has a specific target that is stated in the very first page of Kent Beck’s book: “clean code that works”.

“Clean code” means code with a good design, intended as a design that makes it easy to read and maintain the code. “That works” means code that does what we expect from it. Tests we use to drive the process allow us to achieve both: if they are green, our code is working - and thanks to those tests, we can easily refactor our code to improve its design being sure that the behavior is still the same.

The focus of TDD is not only on testing, is “clean code that works” and the test-driven process is the best way known today to achieve that result - it also allows us to split the problem: we write the tests and make it green, focusing on “code that works” - then, we refactor focusing on “clean code”.

TDD doesn’t take care itself of it: it’s up to you to be sure you know what the software is supposed to do to write useful tests, and it’s also up to you to know the best design and refactor practices to apply - once you know those, TDD is the best tool to be sure you achieve them both.

TDD is not flexible

Prosecution

Now, your honor, please let us now cast our gaze upon the notion of inflexibility. As opponents of TDD, we want to present an argument that has struck at the very heart of its methodology, contending that the rigid nature of this approach, which insists on writing tests before any code, may stifle creativity and innovation.

The prosecution asserts that this critique is a striking indictment of TDD's potential drawbacks. We argue that the demand for tests to precede coding creates an environment where creativity and exploration take a back seat, as it's not conducive to imaginative problem-solving or the pursuit of alternative, innovative solutions.

In our ongoing scrutiny of TDD, the notion of inflexibility is indeed a substantial concern. It prompts us to consider whether, in its zeal to ensure testing, TDD might inadvertently suppress the very creativity and out-of-the-box thinking that often leads to groundbreaking software solutions. The prosecution submits that these allegations, while disputed by proponents, are nonetheless serious and warrant careful consideration as we weigh the merits of TDD in the realm of software development.

Defense

Letting aside the attack about TDD being focused on testing, that we already responded to in the previous point, we want to totally refuse the prosecution accusing TDD of being inflexible.

In this case, we can start our responding taking inspiration directly from Kent Beck’s TDD book itself: in the “Mastering TDD” chapter, the author respond to some hypothetical questions that may arise when trying TDD. Among all the incredible insights of this chapter, one of the questions is: “How much feedback do you need?”.

The question is about feedback because tests in TDD are described as a way to have a short feedback loop about our decision, so this question can actually be rephrased to “How many tests should I write?”. And the answer is: it depends!

With a very clear example, Beck shows us how the same problem caused him to write 6 tests, while another developer wrote 65. Quoting the book:

You will have to decide, from experience and reflection, about how many tests you want to write.

TDD's view of testing is pragmatic: tests are a means to an end, the end being “code in which we have great confidence”. Taking this idea to the limit, it means that if our knowledge of the implementation gives us confidence even without a test, then we might even decide to not write a test at all.

In the end, this means that the more you know the problem you are solving with the code, the less number of tests you will feel the need to feel safe - and as a consequence, you will write fewer tests. On the reverse, when you are facing a problem for the first time, you will probably prefer to have a lot more tests to feel safe.

And that sounds like a very flexible approach to me!

Next week, we will discuss the last 4 points, and then I will share my take and conclusions, as always, and also the most important resources I know to understand more about the impact of this practice.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Happy Halloween 👻

🎉 Hey, developers! This week, a special edition of the newsletter is coming to your inbox! We celebrate Halloween with an AI-generated Horror Story about Software Development. I asked ChatGPT to help with this, giving “The Blair Witch Project” movies as a reference. Hope you will enjoy this week's email, and have fun on your Halloween night! 🎃

In case you feel the need for a technical read - check our archive here!

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

🧙🏼‍♀️The Blair Witch Project: a Software Development Horror Story [Halloween Special 🎃]

The moon loomed high in the dark, starless sky. Sarah, Mark, and Mike ventured into the dreaded "Black Code Forest," a cursed software development project whispered about in hushed tones among the bravest programmers. It was an insidious place, shackled by malevolent waterfall practices. Automated tests had long been sacrificed to the project's spectral forces, leaving a void for chaos to reign. The team's mission: to rescue this forsaken codebase.

With laptops as their torches, the intrepid trio crossed the threshold of the "Black Code Forest." A sense of unease fell over them as they waded deeper into the labyrinthine codebase.

Within the dimly lit corridors of code, ethereal whispers grew louder. "No version control," they hissed. "Manual deployments." "Untested changes." The voices swirled around the team, a constant reminder of the dark past that had trapped the project in its cursed state.

As they trudged forward, the ominous nature of their task became apparent. Deadlines loomed like specters, never allowing a moment's rest. The shadow of perpetual overtime and the threat of burnout weighed heavy on their shoulders.

Sarah stumbled upon a terrifying chart - the "Graph of Doom." A menacing illustration of the project's trajectory into chaos. It was a cruel reminder of the arduous journey that lay ahead.

Merge conflicts, like malevolent spirits, haunted their work. Eerie error messages echoed with chilling warnings: "Conflicts found. Resolve or be doomed." The team fought the spirits as they clawed at their code, desperately trying to break free.

Phantoms of broken code materialized before them. Lines of logic twisted and turned, defying all reason. The team, engulfed by the mystic fog, pursued the elusive specters through the labyrinthine passages.

The fateful night of deployment arrived. It was a harrowing ritual, one that came once a year. The process was riddled with unexpected errors, and the team's nights were consumed by dark sorcery. It was a tradition that none wished to perpetuate.

In their darkest hour, the team remembered the wisdom of software development best practices. Agile methods, automated testing, and continuous integration became their talismans. They decided to fight back, determined to banish the project's malevolence.

With renewed resolve, they set about to break the curse that held the project in its icy grip. They summoned practices like TDD, CI/CD, and automated testing, beginning the process of exorcising the sinister forces that had tormented them.

The day of reckoning came at last. With courage and an unwavering commitment to best practices, the team performed the final deployment. They bid farewell to the legacy code, leaving behind a well-documented, efficiently maintained software. The curse was shattered, and the "Black Code Forest" vanished into the mists.

This chilling tale serves as a reminder of the horrors that can afflict software development when best practices are abandoned. The curse of legacy code, manual deployments, and an absence of testing can torment even the bravest. However, with dedication and the right practices, the curse can be vanquished, and the nightmare can finally end.

Happy Halloween, fearless developers. Remember, in the world of software development, the specters of bad practices and legacy code are very real. It's up to you to decide whether to banish them or let them haunt your projects.

Until next time, happy coding! 🤓👩‍💻👨‍💻

🎉 Milestones Reached 🎉

🎉 Hey, developers! The biggest news of the week is that I launched my first free Workshop: a 4-hour deep-dive into TDD basics to use it as a learning tool, and OOP misconceptions. The even bigger news is that the 8 seats available went sold out in a single day! It was amazing, and I will definitely setup new sessions in the future, so… stay tuned!

📌 In case you missed it: last week, I gave my 2 cents about AI's impact on Software Development jobs: where we are, where we might go in the future, IMHO! If you haven't already, make sure to take a read at it here and let me know what you think! 💪

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

🚀 What's the Real Deal with Documentation in Agile? 🤔

Introduction

Documentation is a frequent source of heated discussion when it comes to Agile practices. Discussions can become rather animated as people from different backgrounds and experiences bring their unique viewpoints to the table. Some people say that Agile and documentation cannot coexist because they are incompatible, comparing them to oil and water. On the other hand, other people believe that documentation is an essential and crucial component of the Agile process.

Maybe you are one of the believers that Agile says to avoid documentation completely. We're here to debunk this myth.

The approach to documentation that Agile and Extreme Programming take is sometimes misunderstood or misinterpreted. So, in this post, we'll go into the essence of XP and expose the true nature of Agile documentation as it relates to this powerful and dynamic methodology.🚀📝

The Truth About Documentation in Agile

Let’s start by stating the truth very clearly: in no way does Agile Manifesto, XP, or any other Agile-related methodology suggest avoiding documentation completely.

I mean, that wouldn’t make any sense, right? Some documentation is just needed, sometimes. Think about audits, support, onboarding, tracking decisions, brainstorming - there simply are good reasons to document stuff, sometimes.

The only real take about documentation is:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

[…]
Working software over comprehensive documentation
[…]

That is, while there is value in the items on the right, we value the items on the left more.

The Agile Manifesto states very clearly that “there is value” in documentation, but working software is considered more important - and hopefully, this is something we all agree on.

The problem is that, over time, some people misunderstood this sentence and spread the idea that all documentation should be avoided. This is simply not true and is one of the things that contributed to making people skeptical about Agile.

Still, most people underestimate that statement - and I think that to clarify it we need to bring eXtreme Programming's take on documentation when describing the principle of “mutual benefit”:

Extensive internal documentation of software is an example of a practice that violates mutual benefit: I am supposed to slow down my development considerably so some unknown person in the potential future will have an easier time maintaining this code.

This is the big problem with extensive documentation in most organizations, IMHO: while some consider the cost of documentation, almost no one considers the ROI of that cost - that most of the time is very low.

Writing technical documentation has a lot of issues:

• writing good technical documentation is hard, for multiple reasons:

  • even writing well in general is hard

  • writing good technical documentation is a different job than writing code

• async written communication is generally less efficient than sync conversations (and the fact that writing well is hard doesn’t help)

• it is completely detached from the codebase, so you need to invest effort to be sure either you don’t have duplicate info between code and doc or to keep that duplicated info in sync

I’m sure most of you feel related to those problems, but you probably think that documentation is still important and we just have to do it.

I agree, we need certain types of documentation, but not all.

The heuristics we should care about

From all the ways to think about software documentation, I like the approach of splitting it into two main categories:

• Product documentation → here we have all the documentation we write for users (both internal and external), but also all the documentation related to the system - for example, API public documentation and Architecture documentation fall into this category

• Process documentation → here we have all the documentation we produce during the process of development = for example, user stories and meeting notes fall into this category

We can safely say, IMHO, that Product documentation is the most important one to invest in - because it will last over time; Process documentation instead, is only useful in the process, then it becomes mostly useless.

This is one of the keys to approaching documentation in an Agile (and smart) way: consider trade-offs like we always do in code (or should do!). If the Product doc is more important, we want to invest more time in it compared to the Process doc.

Talking about the mutual benefit example we discussed earlier, the solution is not to don’t write documentation at all - XP simply suggests a different approach:

• Invest time in writing automated tests instead of documenting the code what it should do and how to use it - this way not only benefit will be mutual (for both the current dev and the future one) but in general the code will be easier to read and maintain

• Invest time in refactoring instead of documenting the code to explain what it should do in detail - this way, we can remove accidental complexity and improve readability, giving the current dev more satisfaction and fewer defects, and also an easier-to-understand code for the future dev

• Invest time in names to make them explicit and coherent, so that the current dev works faster and future dev will easily read it

The point is not to avoid documentation, but to handle it in a professional and smart way - not writing any doc or writing too much doc without thinking are just 2 faces of the same, problematic coin.

Basically, we should handle the documentation the same way we treat code and tests: the less it is, the better; the more automated it is, the better; the less duplication there is, the better; and so on.

Here are the principles and heuristics that we can follow to face documentation in an effective and sustainable way:

• Code should be self-documenting → the right place to read what the code does is the code itself: instead of writing documentation to describe it, refactor it to make it readable

• Tests are living documentation → tests are still code, and they basically are examples of usages of the code under tests: make tests readable so that they can actually be useful as documentation

• Automate all the documentation possible → writing documentation is painful, and keeping it updated with changes is even more painful - be sure to always ask yourself if a piece of documentation can be automated, and pick your tools to enable the automation chances; documentation is costly, we need to reduce that cost

• Keep documentation close to what it describes → instead of having a single place for documentation, make sure you document something very close to where you use it - a centralized wiki makes a lot of sense for company-wide and product documentation, but, for example, document your codebase in the repository itself

• Write just enough documentation → “just enough” means be sure you write all that truly matters, in a clear way, but no more; it also means be sure to cover all that matters

• Write documentation “just in time” → before documenting, wait. Produce documentation when it’s needed, not before - a similar approach to creating an abstraction: do not do it immediately, wait until the last responsible moment when you are sure you need it and most information is now steady and not changing continuously.

Just as clean code and solid architecture contribute to a healthy project, so does comprehensive and well-maintained documentation - and missing/wrong/bad documentation also contributes to technical debt, so again, “just enough”: write all that’s important, but no more.

This synergy can help us steer clear of the ever-dreaded tech debt, maintaining a system that's truly agile, adaptable, and ready for the future.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

I’m pretty good at documenting stuff - at least, this is how I feel about it, due to some self-reflection but also the feedback I got in my career.

The truth is: that I hate documentation - so I had to learn how to handle it in order to avoid writing too much.

At first, I did some research, because you know - it’s not like you can stop doing something just because you don’t like it, it is not professional. I wanted to understand how people were handling documentation.

In the first years of my career, when I still wasn’t into Agile, all I could find was a lot of tips on how to write and maintain a big documentation. I’ve never been able to make it work, and I’ve never seen people that have that approach to documentation making it work properly.

Documentation is just part of the Agile and XP revolution that I faced years ago: in the same way that I discovered that there actually are ways of developing software successfully, there also are ways to handle documentation successfully!

Differently from code, where we can identify a lot of practices to approach development in an Agile way (TDD, CI, etc..) - on documentation we mostly have principles and ideals.

Today, I want to give you an example of what we set up in my previous team, where I was tech lead and we tried to handle documentation in the most lightweight and agile way we could think of.

1. Distributed documentation

   
   In a similar way to distributed services and microservices, we tried to approach documentation in a distributed way: we tried to keep the documentation always as close as possible to the thing we wanted to document.
   
   Everything related to the codebase was in the README file in the repository - things like a description of the project, setup requirements, and domain knowledge that it’s worth an explanation of why it’s implemented that way.
   
   We had a 2 layer Wiki (made with Notion) - layer 1 was company-side documentation, used for organization stuff like describing the company the business, etc; layer 2 was the products, each product had a dedicated sub-wiki where documenting all the things related to that product (POCs, External APIs or Hardware tools doc, Meeting notes, etc).
   
   We also had an ADR repository: we used the Any Decision Record interpretation, and there we tracked all company-wide tech decisions, such as the format for money and date in our internal APIs.
   

2. Prefer automation

   
   We were a small team of a small startup, so it was fundamental for us to consider the impact of documentation on our productivity - and being able to automate documentation was a game changer for us.
   
   Here is the best example of it: we didn’t need a Swagger documentation API for external users - our API was only used by the front end. At first, we automated Swagger doc from code - then, we evolved it to create the Typescript types library and automatically share it from BE to FE. This way, we automated the creation of 90% of boilerplate code - we only needed to implement the client class using that type, we had a standard way of handling exceptions and the only thing that remained to share was special error cases. Another future improvement we planned was automating the entire SDK instead of only the types of Requests and Responses, but we didn’t achieve that before I left.

3. Pick tools that enable automation

   
   It’s fundamental to choose your tools with automation in mind: for example, we choosed Notion because thanks to its APIs we had the chance to automate some kind of documentation - for example, we automated the publication of approved ADRs, and when I left we were working in automating release notes using Notion as CMS.
   
   Having tools such as Notion, with official API included in the plan. will always enable you to automate stuff as you need - and most of time even without implementing due to an existing integration via Zapier/Make.
   

4. Consider the trade-offs

   
   In the same way, we need to consider trade-offs when implementing something in the code, we should do the same with documentation.
   
   The simplest example: is if you need to invest 1 hour to document a change that requires 15 minutes of implementation, you should ask yourself if it’s worth it. Probably, you can reduce that time - probably, you are documenting way more than “just enough” needed. Be sure to document everything that’s worth it, especially the whys and constraints that lead to a certain decision.
   
   But be 100% sure that everything you write in documentation is worth the time.
   

5. Shared responsibility

   
   Writing documentation is not the responsibility of a single specific person, even if he was the one working on the related part. Everything related to the product should be a team responsibility, following Agile principles - and documentation makes no exception.
   
   Be sure that automation is the priority for everyone when it comes to documentation, and that the written documentation that you still need to write is written by a different member every time so that the pain is shared.
   

This is just an example, something that worked pretty well for us in a context where documentation was only internal and we were driving it as a best practice - so basically the company trusted us in most decisions.

In your context, you could of course face more constraints (stakeholder needs, user-facing documentation required, etc) - but following the same principles and heuristics shared in this article, you should be able to handle it successfully without making developers suffer!

Go Deeper 🔎

📚 Books

• Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects - Documentation is the castor oil of programming. Managers think it is good for programmers, and programmers hate it!

• The Product is Docs: Writing technical documentation in a product development group - This book provides a broad perspective on the essential aspects of creating technical documentation in today's product development world. It is a book of opinions and guidance, collected as short essays.

📄 Blog posts

• Agile Development Methodology and Documentation

• Software Documentation Types and Best Practices

• Types of Software Documentation to Know About

• Documentation in Agile: Challenges and Trends in 2023

🎙️ Podcasts

• Agile Myth Busting: is there really no documentation in Agile?

• Easy Agile Podcast Ep.14 Rocking the Docs

• A Roadmap to Agile Documentation

🎉 Milestones Reached 🎉

🎉 Hey, developers! As every week, we keep growing due to a new subscriber that joined LAP 🆓 - let’s welcome him among us while hitting 45 subscribers! 🙌 Thank you all so much for your support - please, share this content to your fellow developers to help LAP keep growing!

📌 In case you missed it: last week, I entered the highly discussed topic of monolith vs microservices and gave my thoughts on how, sometimes, that decision is not merely technically but more sociotechnical and team-structure-dependent! If you haven't already, make sure to take a read at it here and let me know what you think! 💪

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

AI and Software: 🤖💻 What's the Synergy We Can Expect?

Introduction

Are you ready to navigate the exciting terrain of AI in software development, but perhaps a bit apprehensive about the future? 🤖

As technology continues to advance, there's a growing fear that AI might replace many human workers, including programmers. But wait, there's another side to this story.

🌟 Embracing AI doesn't just mean relinquishing control; it means unlocking new opportunities for creativity and innovation in the software realm. In this article, we'll journey through the realm of AI, addressing those concerns while putting a different light on the incredible possibilities it brings.

So, let's embark on this adventure together and explore the synergy of AI and software development. 👩‍💻🚀

What do we mean with AI?

Artificial Intelligence (AI) is a phrase that's been circling the tech world for decades. But what does it actually mean, and how is it relevant to software development? Let's start by demystifying AI.

Defining AI

At its core, AI refers to the ability of machines or software to perform tasks that typically require human intelligence. These tasks encompass a wide range of activities, from recognizing patterns in data to making decisions based on that data. In the context of software development, AI can revolutionize how we approach various tasks, from coding to testing.

Since I’m not an expert in the field of how AI works - I prefer to send you an article from more expert people to read more about this. You can find it here.

AI in Everyday Life

AI is no longer confined to the domain of sci-fi films and research labs. It's integrated into our daily lives, from personalized movie recommendations on streaming platforms to self-driving cars.

AI's ability to sift through vast datasets, identify patterns, and make informed predictions can revolutionize various aspects of our jobs, software development included.

The current landscape of AI for Software Development

The integration of AI into software development is not a distant dream. It's happening right now, reshaping how we conceive, build, and manage software applications.

1. Code Generation and Auto-Completion

One of the most immediate applications of AI in software development is code generation. AI-powered tools analyze your programming tasks, understand the context, and suggest code snippets or even generate entire functions. This can, potentially, drastically speed up the coding process.

2. Bug Detection

AI algorithms excel at spotting anomalies in large datasets. In software testing, AI can pinpoint irregularities in code execution, making it an invaluable asset for identifying and fixing bugs. This contributes to the development of more robust and reliable software.

3. Predictive Analytics for Software Maintenance

AI's predictive capabilities extend to software maintenance. By analyzing historical data, AI can forecast when components or systems may fail or require maintenance. This allows developers to proactively address issues, reducing downtime and enhancing user experiences.

4. User-Centric Application Customization

Incorporating AI enables applications to adapt to individual users' needs. Whether it's suggesting content or tailoring the user interface, AI enhances user experiences and increases engagement.

5. Advanced Security Measures

Security remains a paramount concern in software development. AI plays a pivotal role in detecting and responding to cyber threats in real time, fortifying the software against potential attacks.

AI in the Cloud

Cloud platforms harness AI to streamline software development processes. These platforms offer scalable resources, support collaboration, and facilitate DevOps practices.

Emerging AI Trends

As AI in software development continues to evolve, emerging trends show its vast potential. Natural Language Processing (NLP) enables code to be written in plain English. Reinforcement learning can optimize code execution. AI chatbots are transforming customer support in software applications.

Will we all lose our jobs?

As AI continues to weave its way into the software development landscape, a significant concern looms: will AI make software developers obsolete?

1. A Shift in Roles

AI will not replace developers but rather redefine their roles. Routine and repetitive tasks, such as code generation, will become automated. This allows developers to focus on higher-value activities like problem-solving, architecture design, and creative innovation.

2. Continuous Learning is Key

The symbiotic relationship between AI and developers necessitates continuous learning. Developers must adapt to this new environment, learning to collaborate effectively with AI systems and harness their capabilities.

3. Enhanced Productivity and Efficiency

AI augments developers' productivity. It offers recommendations, identifies potential issues, and accelerates coding tasks. This synergy fosters efficient software development.

4. Job Evolution, Not Extinction

The role of a software developer is not disappearing; it's evolving. Developers become AI partners, utilizing technology to create sophisticated, intelligent, and user-centric applications.

5. Ethical and Creative Aspects

AI cannot replicate human ethics, creativity, or empathy. Developers remain essential in making ethical decisions, creating innovative solutions, and understanding user needs at a deeper level.

The partnership between AI and software developers holds immense promise. As AI tools become indispensable, software development will become more efficient and innovative. Developers' jobs will transform, aligning with the evolving technology landscape. The future is bright for those who embrace AI as a powerful ally in the realm of software development. It's not about job loss but about a new era of enhanced capabilities and endless possibilities.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

If you know me, you already know how I see our job: we are problem solvers, and code is just one of the tools in our toolbox - AI is just another one.

So, in general, I don’t think AI will replace our job entirely - mostly because of two reasons:

• first of all, we often solve context-specific problems, and this means that standard solutions and known solutions can be reapplied only if adapted to context, considering tradeoffs, constraints, etc - there will probably be some problems that we will solve with prompts instead of code, but I don’t see a total replacement here

• also, someone will have to develop AI, develop tools around them, integrations, and so on - there will be new opportunities also, not only something less to do

At the moment, the best thing we can do as software engineers is try to understand how AI can be useful to us.

How do I use AI?

In general, I’m still a bit skeptical about the current status of AI for coding, and I’m going very slow in experimenting it: for example, GitHub Copilot is still not in my daily coding routine.

I’m experimenting with some stuff, for example, an AI-TDD CLI tool that basically allows me to call a command specifying a test, and he will respond by creating a class implementing a code passing that test.

This is the first great usage that I see today and I want to start experimenting in deep - it’s also a path that I think can become more powerful in the future: I’ve seen some people making AI creating tests for the code they wrote, but I don’t like that approach.

As a sustainer of TDD, I strongly believe that the most important part of the code is the test: if written first, the test guarantees us to make the code do what we tested, but also decide how it is used - and then leave the implementation to AI. This makes so much sense to me because it allows humans to help AI in context stuff (one of the weaknesses of AI, at the moment) by deciding class and method names - and also allows us to have control over what AI produces with an automated test.

The green tests are all we need - and the tests will become the most important code for humans to maintain - and can probably even evolve to some “more human” language than code, maybe even some prompts, but more controllable.

I see a lot of potential in this approach: if such a tool will gain the ability to have more context from the project, we could see a real big change: we don’t even care if the code is maintainable because it’s AI that maintains it so making it more readable in the implementation doesn’t make that much difference. We could forget about SOLID and other Clean Code principles and just care about the external interface - that will remain the most important thing. I know it looks very far from now, and some of you might think that I’m crazy, but I truly believe in this.

Another point where AI could be useful is documentation - there already are a lot of ways to automate documentation of multiple kinds, and with AI these tools could become so powerful that we could even automate everything, maybe. Imagine running commands that are able to create the Swagger documentation only by reading code, without any comment in the code - or the same for C4 Model documentation, UML, etc.

We will always need some sort of documentation, especially for APIs or libraries we offer to the external world.

In general, anyway, the most realistic future I can imagine is one where the focus of software developers is building systems where AI can automatically generate code and we build what’s needed to be sure that what AI built is correct and is actually what business needs.

This also means that, at least for a couple of decades more, there will still be a lot of work for software developers - especially those that deep dive into practices and methodologies because they will come in handy for sure in the transition to AI-generated code, but I’m sure they will be helpful also once AI will generate code we can trust more.

Go Deeper 🔎

📚 Books

• Artificial Intelligence For Dummies - Starting with a basic definition of AI and explanations of data use, algorithms, special hardware, and more, this book simplifies this complex topic for anyone who wants to understand what operates the devices we can’t live without.

• Artificial Intelligence Basics: A Non-Technical Introduction - Artificial intelligence touches nearly every part of your day. In our modern era, an understanding of AI and its possibilities for your organization is essential for growth and success.

• Probabilistic Machine Learning: An Introduction - This book offers a detailed and up-to-date introduction to machine learning (including deep learning) through the unifying lens of probabilistic modeling and Bayesian decision theory.

• Fundamentals of Machine Learning for Predictive Data Analytics - This introductory textbook offers a detailed and focused treatment of the most important machine learning approaches used in predictive data analytics, covering both theoretical concepts and practical applications.

📩 Newsletters

• The most impactful AI events of 2023 - [AI Supremacy newsletter from Michael Spencer]

• Last week in AI newsletter

• Use AI, a practical AI newsletter

📄 Blog posts

• Can AI help you code?

• AI for Software Development: Use Cases and Challenges

• The rise of AI in software development

• How generative AI is changing the way developers work

• There’s an AI for that - a collection of AI tools, daily updated

🎙️ Podcasts

• AI And Machine Learning – Story Of Software Podcast

• The future of software and AI

• 20 AI Podcasts to Learn More About Artificial Intelligence

🎉 Milestones Reached 🎉

🎉 Hey, developers! As every week, we keep growing due to a new subscriber that joined LAP 🆓 - let’s welcome him among us while hitting 45 subscribers! 🙌 Thank you all so much for your support!

📌 In case you missed it: last week, I made my call into the “microservices yes or no” topic, explaining why I think that we must always consider DDD Strategic approach and Team Topologies organizational pattern in the decision! If you haven't already, make sure to take a read at it here and let me know what you think! 💪

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

Choosing Wisely: When to Go Sync ⏳ and When to Go Async ⏰ in Software

Introduction

We are presented with a paradox that is becoming more and more common in the dynamic world of contemporary software development: the decision between synchronous and asynchronous work. Even if the globe has seen a tremendous shift towards remote employment, it's important to remove a myth. Asynchronous work and remote work are not always related. They are two separate dimensions that are capable of coexisting or functioning separately.

When we accept remote work, we admit that the distance between us no longer limits our capacity for productive collaboration. The choice of whether to operate synchronously or asynchronously is dependent on a diverse set of factors, and it has a significant impact on the outcomes we generate.

We'll examine the circumstances in which each strategy excels in this blog article, delving into the nuances of this decision and probing the reasons why, more often than not, synchronous work emerges as the cornerstone of high-quality software development. While asynchronous work undoubtedly has advantages, we'll explain why maintaining a careful balance between the two is necessary for long-term success in the software development industry. I will also try to suggest one possible approach, in my personal take section.

So let's start this trip to learn how to make sensible software decisions about when to go sync and when to go async.

🚣 Navigate the realms of sync and async

Asynchronous (async) and synchronous (sync) are two characteristics of the way a team or organization decides to work: that decision determines the pace and flow of the work, dictating some constraints in how we handle tasks and processes within our daily work. Understanding the differences between these two paradigms is essential, particularly in a world where remote work is becoming more and more common.

What Distinguishes Sync from Async, then?

First of all, is important to notice that it is mostly communication that can be sync or async - but communication is such an important thing that this decision has an impact on the entire workflow.

Synchronous communication is the one we are used to: people are available all at the same time, working in the same hours (mostly, at least) and then they are able to communicate to each other immediately when required: response is expected in minutes because we know that we are all available together.

On the other hand, we can handle communication in an asynchronous way: people are not required to share any hours to work contemporarily and therefore are not expected to be necessarily working when someone else is working. If someone needs to communicate with someone else, the expectation is that response might even take hours, or an entire day, because the other person might work in a completely different time.

These two approaches to communication, as I already mentioned, have a huge impact on how we work: async communication implies that everyone is working mostly solo, so people are required to be autonomous, and if you need some help you will probably have to wait a lot so you should be able to find out a way to make that waiting time productive anyway.

In the last years, with remote working becoming quite normal all around the world, a lot of companies went into the path of being fully (or mostly) async in communication, and therefore also in how they work: in such organizations, work is typically handled with a feature branch for each developer, with Pull Requests at the end; you might have a single daily touchpoint with a standup that is typically just an update (and sometimes can be also async) and then work in solo the rest of the day.

I think this is a very big mistake from companies - or, at least, most companies working this way are not aware of the impact of that choice on software development, which is typically a negative impact.

🚣 Pros and cons of async work in Software Development

In general, when working remotely, async communication is a very powerful tool, that can improve employers’ lives and productivity: I won’t deny this.

Some benefits are:

• communications are not urgent by default and they become urgent only when actually needed (when we are sync, it’s easily the reverse, which is a big mistake)

• it’s easier to have some focus time - office context can be quite distracting, and sometimes we just need to focus

• a better work-life balance, which is definitely the biggest pro of being able to work whenever we want

These are just some of the reasons why async communication makes a lot of sense, sometimes. But when it comes to Software Development, things are different.

If you are here, you probably heard about the Agile Manifesto: if we try to follow the Agile Manifesto we realize that async communication is an obstacle to it.

Let’s have a deeper look at the 4 values:

• Individuals and interactions over processes and tools

  This is very reversed in async communication - every developer works on its own, with no chances of pair/mob or any feedback before the async PR - that, BTW, becomes an actual process in that context; if we go fully async, we are giving power to process and tools, instead of giving it to people

• Working software over comprehensive documentation

  This is also the opposite when async - the reason is that we want to favor async communication as a default, so one of the consequences is that we think we should document everything at the highest level of detail possible; the problem is that documentation should be only for things that don’t change - but if you do that, it’s probably not enough for a completely async approach, so you fall into the mistake of documenting details, and either failing in keeping it updated or invest a lot of hours in doing it, with a negative ROI then compared to when and how much it will be useful

• Customer collaboration over contract negotiation

  This becomes mostly impossible when working async - collaboration, actual collaboration, require a lot of sync communication; we cannot actually collaborate if we only communicate async via text, email, or documentation; then, it only remains to negotiate contracts, typically based on estimates and due to that, since estimates are guess and will be wrong by default, based on wrong data.

• Responding to change by following a plan

  Finally, the 4th point also becomes mostly impossible: typically, you cannot respond to change on your own, for multiple reasons - you might not have access to the feedback autonomously, you might require some approval to change the solution away from the original plan, etc. If you have to wait hours, or days, to have feedback on changes, you will be inclined to avoid changes and follow plans without looking for faster feedback. This, again, has been proven to be non-productive in the software development world.

Basically, I don’t see a way to be Agile when working async; actually, I don’t even see how you can consider that a team: they are more like individuals that contribute to the same codebase. And if you are not Agile and do not develop your digital product as a team, you will have hard times.

🌍 The best of two worlds

What to do instead? I will dive more into my ideal approach in the “Dan’s take” section, but here are the guidelines I would follow:

• keep async as default with company-wide non-urgent communications: unless you have to announce something urgent or very important, company-wide meetings can be easily recorded to allow people who cannot be there LIVE to see the recording later

• keep async as default with people from different teams: this is still a good idea because communication should be non-urgent by default, and this is easier when async

• make sync the default within the same team: given for granted that we have cross-functional teams built around our products/projects, we should favor the collaboration among the team

• keep a couple of hours of async: it is fine to keep some async time for people to offer flexibility and freedom - for example, sticking to only 6 hours of expected sync work is a good approach

• implement Continuous Integration: CI requires you to merge code into the main branch at least daily - this will lead the team to a more strict and frequent collaboration in a natural way

In general, remember that working together works best in most contexts, software development included - I know that working from home is a great opportunity for freedom and flexibility, but we should also consider our responsibility for the success of the company and the quality of the software.

Also, the most important thing: being async and being remote is an orthogonal decision: they are totally non-related! I’ve seen teams working async in the office, without any kind of collaboration (and no, a coffee break or lunch together is not collaboration) while I’ve been in a team working remotely pairing/mobbing/collaborating all the time.

I know what you are thinking: staying on call is tiring. I know. But while remote work is a great perk, we cannot expect it to be only pros without any cons. It is tiring, for sure, because it’s work - we can face this by learning to take proper breaks, for example.

With great powers, comes great responsibility.

Be responsible when deciding to go sync or async.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

You know, it’s weird because for some reason we think that the approach that works great for Open Source can work also in a product/project context - but they are very different!

In Open Source, the maintainer(s) of the library receives contributions from individuals all over the world; they never know who and when someone might send a contribution, and they don’t share any objective together with them. In this context, async PR is the only way to work, allowing for different time zones and a safe way to check that the contribution is correct.

When we work in a product/project we should be working in a team.

Here are some definitions of a team:

• a number of people who do something together as a group

• people working together as a group in order to achieve something

• a group of people who support a particular person or point of view

As you can see, a team works together and has shared objectives: while objectives might be clear and shared in an async context, working together is totally removed, taking inspiration from Open Source - total nonsense, in my opinion.

In a company context, whether it’s a product or project team, we should favor other things:

• product/project success

• company profit and safety

• software quality to ensure profitability grows over time

• faster feedback loop and smaller releases to favor gathering feedback from customers

With this in mind, I want to state something very strong: I think that flexibility is a great benefit, but we should never take advantage of it before considering the impact on the company. Total flexibility given from a full async can be good from some point of view, but we are not doing the best for the company: at best, we are still making money but we could be making more, but we must at least be aware of the trade-off we are taking.

What I want to say is that sometimes I feel that people only want flexibility without considering the impact of it. It’s like freedom of speech: of course, everyone has the right to say what he wants, but this is not just a right, it’s also a responsibility.

If you offend someone, you must be aware that you are responsible for that. If you talk about a topic you know nothing about, you must be aware of it. And so on.

The same is true with flexibility: if you are allowed to work from home, you should consider the impact of it: it’s not “the same:”, it’s different - let’s be honest on this, especially because most of the time is better.

What I would do, then? Well, following the principles listed above, here is how I would set up my remote organization:

1. 6 hours of expected sync work - there are a couple of solutions that I would be testing: one could be a single time frame between 10 am and 17 am, including lunch; a different approach could be to split it into two time frames, for example, 9:30-12:30 am and 14:30-17:30 pm; both have pros and cons about lunchtime and starting time, I would probably discuss this with the team

2. Daily standup at the beginning of the sync work - a proper standup is really useful for a collaborating team: it is not a moment of update, it is the moment when we organize the starting day; set up pairing or mobbing session when required, highlight any blocker or issue where some help might be needed, etc.

3. Waiting time rules of thumbs - I would suggest a list of possible activities to be done when someone needs to wait for sync time; this comes from the fact that I would suggest working in single-piece flow, meaning doing one thing at a time, also meaning that if a waiting time is required, you shouldn’t start a new task; some things that are valuable can be: looking for open PR and check if an async review is enough or not, have a look at future tasks to be refined to be ready for it, or even study something (which is always a great investment)

4. Email communication avoided (unless required, for example when talking to someone external) and Slack/Discord chat as a default communication tool: Slack or Discord are great for building a digital office setup, but I would still keep and cultivate a culture of non-urgent communication by default: response are not expected in a bunch of minutes, even if it’s a chat - in the past, for example, we had a “Pomodoro” rule: wait at least one Pomodoro (25 minutes) before pushing for a reply

5. Continuous Integration is a must: while I love Pair/Mob, I know that not all developers love that - so, while I would suggest them as a daily practice for sure, I would leave the final choice to the team; my guidelines, anyway, would only accept practices that enables CI: no feature branches, and in general no branches longer than a day; fully automated test suite; etc.

Of course, all of those points would be discussed with the team, and the final setup and balance would be found with them because I truly believe in giving responsibility and trust. But still, these are my main ideas.

What do you think? What would you do instead? Feel free to let me know! :)

Go Deeper 🔎

📚 Books

• Remote Team Interactions Workbook: Using Team Topologies Patterns for Remote Working - In this workbook, the authors of the widely successful Team Topologies provide a road map for organizing effective and happy team-first remote workplaces.

• Sync Async: Making progress easier in the changing world of work - A growing number of teams and businesses are learning and experiencing the value of deliberately working in sync / async ways. You can start working better in both sync and async ways from today. 

• From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver - Distributed agile teams have a terrible reputation. They don’t deliver “on time,” and too often, they don’t deliver what the customer needs. However, most agile teams, have at least one remote team member. And, agile approaches are here to stay. Don’t blindly apply agile practices designed for collocated teams. Instead, learn to use three mindset shifts and the agile and lean principles to create your successful distributed agile team. Use the tips and traps to help your team succeed.

📩 Newsletters

• Remote Work Pulse [A remote work newsletter by Sergio Pereira - I don’t always agree with him, but he is very experienced]

• Remote Work Newsletter by harkirat

• Work From Anywhere newsletter by Mike Holp

📄 Blog posts

• From Async Code Reviews to Co-Creation Patterns

• What Is Asynchronous Work? (Async Working Model)

• Sync vs Async Communication in Remote Work

• When to Choose Synchronous Vs. Asynchronous Communication

🎙️ Podcasts

• The ReWork Podcast

• Distributed

• Managing Remote Teams

🎉 Milestones Reached 🎉

🎉 Hey, developers! As every week, we keep growing due to 4 new subscribers that joined LAP 🆓 - let’s welcome them among us while hitting 44 subscribers! 🙌 Thank you all so much for your support!

📌 In case you missed it: last week, I entered you into the world of Domain-Driven Design, a very complex methodology, especially highlighting the strategic approach that is very powerful to add to your problem-solving skills! If you haven't already, make sure to take a read at it here and let me know what you think! 💪

🔥 Premium updates 🔥

🔥 Personal coaching services seats available: one-on-one guidance from me, Dan the dev, an experienced Agile developer who will help you develop the skills and knowledge you need to succeed in 12 1-hour sessions.

Take advantage of our 2-lessons Money Guarantee policy: enjoy the first two out of twelve sessions and if you are not happy with them, I will refund the entire amount. Discover more 👉 here.

Thanks again for being a part of our journey! 🙏

Discover our products and services

📣 Just a friendly reminder, folks! In our welcome email, you received a sweet discount that's valid for any of my products and services. Don't forget to take advantage of it - it doesn’t expire! 😉

🌪️ What most people don't consider when discussing micro-services: DDD and Stream-aligned teams matter! 🤝

⏩ Introduction

At some point in the last decade, microservices have been considered game-changers in software architecture, and have taken the tech world by storm. Organizations worldwide transitioned from monolithic architectures to microservices, seeking benefits like improved scalability, agility, and maintainability. The allure of microservices lies in their promise to deliver independently deployable and highly specialized components, allowing teams to develop, deploy, and scale services with unprecedented flexibility.

But then, at some point, the realization that microservices also come with their own set of negative sides also spread out - and people recently started a new trend by suggesting to avoid microservices completely, or at least wait for when it actually makes sense.

The discussion about “when it makes sense” became finally important - which is great because every time we make a decision like that in software development, there is always a tradeoff somewhere - and discussing tradeoffs is the right thing to do because the most important thing is to pick conscious tradeoffs - not accidental ones.

So, let’s deep dive into the issue to understand why it’s important to take those aspects into consideration - before even discussing if and when splitting some services into microservices makes sense or not.

🧩 Know your business subdomains

Microservices are not just about creating smaller codebases. They are about creating independent, self-contained services that align seamlessly with your business's needs. Imagine your software system as a vast landscape, and microservices as the distinct territories within that landscape. Each territory (microservice) has its own rules, culture, and language.

What DDD suggests is that we can identify different territories in our company landscape - for example, in an e-commerce business we might identify Shop, Storage, and Shipping territories - and then each of those territories lives on its own, designing its own Product model containing only the subset of data they actually need.

Basically, we split the complexity of a very big and complex business into 3 different smaller businesses, the subdomains, dedicating their own specific smaller systems to each of them; the biggest advantage of this is that we can evolve what Storage needs without worrying about what Shipping needs, as soon as we support a standard communication way between the two territories.

If you are confident enough with the DDD Strategic approach, you probably noticed that this parallelism can be repeated for the organization subdomains: the entire company business is the landscape, and subdomains are the distinct territories within it.

The Shop, Storage, and Shipping I identified in the example - which is simplified but still meaningful - are nothing different than an implementation of 3 different bounded contexts.

Do you see the connection, now?

👨‍👩‍👦‍👦 Structure your teams accordingly

Thanks to subdomains, we now have a clear idea of which territories make sense to split our landscape - and if we follow subdomains, you can be sure that the isolation of those concepts will be a simplification compared to the hypothesis of keeping them all together.

But that is not enough: team structure is also important!

Imagine a group of explorers navigating through the territories of your landscape (microservices). Each explorer has a unique skill set and purpose. The success of your expedition depends on how well these explorers are organized and work together.

We absolutely want the explorers to be autonomous and not depend on anything else to achieve their goals so that they can get out of any issue without problems.

Imagine they are attacked by some animals and they need to fight to defend themselves - if they need to hide and wait for help, it will be a lot riskier and expensive to save them, while if they are able to at least fight for defend himself and run away, they can at least run away safely and then think to the next move.

In software development, we want stream-aligned teams (as suggested by Team Topologies): cross-functional teams focus on a single, impactful stream of work. It can be an entire product or service (the territory), or a single set of features/user journey/user persona (a portion of that territory). The team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible, without requiring hand-offs to other teams to perform parts of the work - like analysis, release, monitoring, etc: the team covers all of them by itself.

👨‍👩‍👦‍👦 Put subdomains and stream-aligned teams together

Okay, so now we know the territories we have in our landscape, and we know that we want to have stream-aligned teams. What’s next?

It depends!

The smallest stream-aligned team I can think of in a standard software development context is made of 4 people:

• Product Manager

• UX Designer

• Backend Developer

• Frontend Developer

Let’s describe the ideal situation with a simple example.

Let’s say we have 2 territories in our landscape: on the team structure level, we will set up Team A, responsible for Territory 1, and Team B which will be responsible for Territory 2. On a microservices implementation level, we want to have at least 2 different microservices: Service 1 (for Territory 1) and Service 2 (for Territory 2), that will communicate with each other in an asynchronous way, without any dependency (Service 1 can work even if Service 2 is down, and vice-versa).

This microservices structure is not merely a technical decision, because it is widely impacted by our domain and subdomains - and we want to build a team structure that follows that subdomains.

Do you know why? Because Conway’s law exists!

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
Melvin E. Conway

On the contrary, when it comes to a specific subdomain, the decision to use microservices to split it into even smaller pieces it’s mostly technical and can be discussed by the team itself. For example, if Team A thinks that it’s worth isolating a piece of Service 1 for some reason, it’s totally up to them and should be invisible on the outside of that subdomain: autonomous teams, remember?

In conclusion, you need to know your domain and subdomain first, then consider your team and organize it according to the subdomains and the number of people in it - finally, you will prefer microservices at a subdomain level, to achieve independence for the team, and let each team decide whether an even smaller split is needed within their subdomain, for technical reasons.

Until next time, happy coding! 🤓👩‍💻👨‍💻

Dan’s take 🙋🏻‍♂️

Every time I come into a microservices discussion, I feel like some topics are missing or very underestimated: of course, when thinking about microservices, is fine to think of possible cons like HTTP requests due to network, data consistency, or global testing, etc. But before getting to those technical decisions, we need to face organizational and team structural problems, related to the Domain-Driven Design Strategic approach, and Team Topologies concepts like Stream-Aligned teams.

In the past, we were used to building a single software system to serve the entire company's needs: typically, this big monolith becomes a mess, with tables that contain a gigantic number of columns because “hey, in the Product model we need all the info to be able to show and sell the product, add it to a cart, but also all the pieces of information about storage, shipping, etc”.

Moving on with our explorer parallelism, in the old days we tried to explore the entire landscape by organizing our people by skills: we could have an Explorers team, Technician team, and Farmers team, for example. Each team organizes its work by itself, and when one needs something from another, send a request and wait for the response when possible.

With stream-aligned teams, instead, we create a single team with all the skills: if we try to do this for the entire landscape, we come up with a very big team containing all the Explorers, Technician and Farmers we have - the problem with that is that is just too much people, and due to how communication works we would be too slow - that’s why we add DDD subdomains to the equation and split people into multiple cross-functional teams, at least one for each territory (subdomain) we identify.

I know some of you might think that not the situations are the same - typically, we can think of the explorer mission in two different ways in software development (mainly):

1. If we are a consultancy company, we probably work by the project: this means our explorers will have an exploration that has a target (a scope and a time frame, typically) - we need to take the best outcomes for that scope in that time frame for our customers, like if someone pays us to send our explorers to get some food in the forest

2. If we work in a product company, it’s like the explorers are in a neverending exploration of the territory we assigned them, and they keep exploring it to get the most (money) out of it in all the different ways we can find according to our skills (business models)

While consultancy contexts are typically harder, especially from the scope and time point of view, it would still be a good idea to set up the organization by stream-aligned team - it could be one team for the project, for example. The fact that a project typically has an end date has no impact on this.

To conclude my thoughts, there are a couple of typical patterns that I want to highlight from the ideal situation described above:

What if we do have not enough people to build multiple teams?

Then you already have a decision about microservices at a subdomain level: keep everything together. Build modular monolith microservices, where every subdomain is easily identifiable, so that code is more maintainable even if all together and it’s ready to be spliced out whenever the time comes. Every microservices split here is mostly technical because splitting in microservices for each subdomain would be a useless overhead for a single team.

What if we discover that Territory 1 could contain another subdomain?

This probably means you discovered a new possible income stream for the company, which is great! While things are still small, nothing needs to change: Team A can work on both. Once the two streams are big enough, and the workload is too big for a single team, you can add a second team to that Territory: at first, you might want to make both teams work on the entire Territory on both streams (two teams sharing the backlog), then, once the second stream is big enough to be on its own, you can even think to split it into two different territories to ensure their independency.

Go Deeper 🔎

📚 Books

• Domain-Driven Design and Microservices - Domain-Driven Design (DDD) concept was introduced by first Eric Evans in 2003. The concept of microservices did not exist at that time. So basically DDD was introduced to solve the problem of a large monolithic code base. This book explores the two topics together.

• Implementing Domain-Driven Design - Implementing Domain-Driven Design presents a top-down approach to understanding domain-driven design (DDD) in a way that fluently connects strategic patterns to fundamental tactical programming tools. Vaughn Vernon couples guided approaches to implementation with modern architectures, highlighting the importance and value of focusing on the business domain while balancing technical considerations.

• Team Topologies - In Team Topologies IT consultants Matthew Skelton and Manuel Pais share secrets of successful team patterns and interactions for IT through four fundamental team topologies and three interaction modes.

📩 Newsletter issues

• Tune in for the 20 years of DDD Stream [Crafting Tech Teams by Denis Čahuk]

• Principles Of The Microservice Architecture [Ravi's System Design Newsletter by Ravi Tandon]

• Amazon Prime Video reduced costs by 90% by ditching Microservices [Technology Made Simple by Devansh]

📄 Blog posts

• Domain-Driven Design for a Modular Monolith: Bridging the Gap Between Microservices and Monoliths

• Applying Domain-Driven Design principles to a Nest.js project

• Domain-Driven Design in the Era of Microservices

• Developing a DDD-Oriented Microservices

• Domain-Driven Design Principles for Microservices

🎙️ Podcast episodes

• Domain-Driven Design and Micro Services

• DDD and Microservices: At Last, Some Boundaries!

• Avoiding Legacy? DDD, Collaborative Architecture and Product Thinking with Nico Krijnen

👨🏻‍🏫 Online courses

• Domain Driven Design & Microservices for Architects (Udemy)

• DDD and Event-Driven Microservices Course

• Domain-driven design and event-driven microservices (O’Reilly)