For the last few days, I’ve been investigating a pesky bug. There’s something appealing to it, it’s the thrill of the chase. While investigating, you get to put on the detective hat, gathering clues and connecting dots, testing hypothesis and slowly piecing the puzzle together.

The detective hat can also be a scientist hat. You start with imperfect information, a phenomenon occurred, but there’s not a working model, a theory, that can explain it, test it, or reproduce it. To go from knowing next to nothing about how this phenomenon happened and how to fix it to a solution, I tend to formulate hypotheses first, and test them. Every time a hypothesis fails, there’s more information for the next one.

In all fairness, a bug sometimes can’t be reproduced at all or with enough consistency, specially when there are many elements involved, all happening at the same time. Think race conditions.

If you can reproduce it, a good idea is to write a test that manifests the bug, so when you have a fix, there’s proof that you’ve actually fixed it.

This week, I’ve experienced a common frustration as a developer, a mix of banging your head against a wall and trying to get out of an infinite maze. To me, it even turns into physical discomfort. It’s the pain of realizing that what should be an easy change is a behemoth, and that untangling the spaghetti might be an odyssey worth being recorded in the annals of history. Soon the odyssey will be forgotten with the next similar challenge, business as usual.

Hours fly by with no progress. At some point, the thought of hacking it might cross my mind, “to hell with it, I just want to move on”. I resist the temptation to hack it because one hack here, one hack there, time over time, only make things worse.

For each desired change, make the change easy (warning: this may be hard), then make the easy change.

The compound effects of hacking it will only make future change more difficult, and even “seemingly easy” changes will be even more difficult to make. Future me won’t be enjoying my hack. But as I sit thinking about the world of endless possibilities and the massive undertaking of the change— compared to what it should’ve been—the value we’re getting from it, and the state of the system, I doubt. In general, my goal is to improve the code in some way with every change, and take many more much smaller steps.

In many situations like this, when I’m stuck, going for a walk, sleeping, taking a break, or just forgetting about it until the next day works best. Letting the subconscious brain do the work works wonders and if nothing happens, at least you see things with fresh eyes and replenish your focus.

Sometimes, it turns out the massive change is not that big when I change the angle of attack. Other times, I realize I was just missing something (knowledge, understanding). The times when it’s really a mess, there could be tons of reasons for it, but two of them appear frequently: the codebase/architecture is not adaptable or the model of the business is obsolete or doesn’t really represent the business.

Physiologically, after banging my head against the wall for hours, the payoff of solving the challenge is like a drug. There’s this immense satisfaction and exhilaration. It’s similar to when you play a difficult video game, die innumerable times, and, with extreme focus and dedication, you beat the boss, or when you finally solve a tricky puzzle in an adventure game. Maybe it’s the sense of discovery, achievement or improvement, like opening a door that was closed until now.

Interesting links

• First One, Then Many. A great article by Kent Beck about succession, which refers to creating a design in stages, starting with a simple design that satisfies the user needs that we know now and evolving it in a lean way.

• Inside Linear: Building with taste, craft, and focus. Lenny from Lenny’s Podcast interviews the CEO of Linear, Karri Saarinen. They discuss the way the company operates and see product, design and software development. Linear is an interesting example of a different way of doing things as a start-up.

• Classic rock, Mario Kart, and why we can't agree on Tailwind. I’ve found this article, by Josh Collinsworth, fascinating. Tailwind has risen in popularity in the past years, but there are two camps of people: the love it people and the hate it people. Josh separates these two camps into builders and crafters respectively and argues that it’s all about tradeoffs and about what we value.

Lately, I’ve been thinking about a common pattern around how we tend to structure our codebase and teams: we favour organizing things around technical responsibilities or by function/skills. It might be a bit of a massive stretch, but in my mind there’s a thread connecting the two—technical responsibilities and split by function.

Let’s see this pattern in the codebase first with a few examples.

Once upon a time, there was a legacy codebase. Based on the folder names, it looked like it was referring to Domain-Driven Design concepts: aggregates, entities, services, repository… Inside, you could see things like OrderAggregate, OrderService, OrderRepository and all kinds of interfaces (IStuff). When I went to see an aggregate it was mostly empty, referring to some other code, and that code was mostly empty, referring to some other code. Travelling the maze of indirection, at the end, I finally saw something meaty. When it was time to extend the logic, it was necessary to unravel the maze, adding interfaces on top of interfaces. This is also a perfect example of an anemic domain model.

The worst part of the indirection maze was that, often, some paths were far from obvious, causing wasted time investigating how to go to the next step.

We’ve organized things by “technical concepts”, categories or by function.

Looking at the teams and the organization, a similar thing can happen. There are plenty of companies with separate front end and back end teams, or separate QA or design departments. Of course, we have the usual marketing and sales teams, or even the infamous DevOps team. We tend to structure the organization into functional silos, making departments by the skill or function they do. We create moats around the functions and limit the collaboration with other kingdoms via queues of work (email or Slack messages, tickets…).

The thing is, you could group front end and back end teams by their shared value streams, but it’s not apparent from the way they are structured that these groups have common outcomes. We can include in these streams the QA and Design team and any other that participates in the production of the product or part of the product.

Let me move to the realm of schools for a second. Based on my little understanding of how schools are organized in the UK, they have separate departments and functions such as attendance or self guarding. Functional silos again. Deep down, these silos share similar goals and should collaborate and communicate effectively to achieve those goals.

Organizing teams by function makes the value stream and shared outcomes hidden. Teams can work on their parts alone, but don’t have a sense of the whole and can’t act on the whole together. Collaboration is stagnant, communication doesn’t flow freely and transversally.

When I look at this, either the codebase or company structure, my mental image of the solution is to turn it inside out, to get what’s shared between the teams or the codebase out of obscurity and make it explicit.

For the codebase, what’s shared, or the umbrella that connects the technical concepts is what produces value, the business flows or, in the case of the UI, the components that the user sees.

For the teams, the umbrella that connects the functions is, again, what produces value, the value stream. Instead of having separate back-end, front-end, QA and design teams (and marketing, sales, etc.) we create a team around the value stream, that owns the outcomes and can act swiftly end to end. The incentives of the new team are aligned, they don’t compete for time or communicate via queues.

Interesting links

• The Siren Song of the ‘User’ Model. Read this article by Chelsea Troy yesterday, and knew I wanted to share it. She argues that the concept of a ‘user’ is extremely vague, not really useful for modelling, and we should avoid it as much as possible.

• Why Startups Fail and How You Can Avoid That. This episode of the Product Thinking Podcast has Melissa Perri speaking with Tom Eisenmann, Professor of Business Administration at Harvard Business School, about six ways startups fail.

• How modular can your monolith go? Chris Richardson, the author of Microservices Patterns—a book I’ve been reading and learning from for a while—is writing a fantastic series about modular monoliths. It shows us how to stretch the monolith to avoid prematurely doing microservices.

Atomic Habits, the book by James Clear, had a massive influence on my life. Reading it made me realize that habits are an intrinsic part of your identify—and vice versa—whether you’re aware of them or not.

The essence of the book could be summarized into the following points:

• Habits influence identity. Identity influences habits. Changing what you do changes what you are, and vice versa.

• Outcomes are a lagging measure of habits. Direction is more important than speed.

• Small habits compound over time to create significant changes, positive or negative.

• Systems over goals.

Hi 👋 ,

I was thinking this week about one of the times I’ve talked to a user.

Looking back at the conversation, there was no preparation whatsoever. I didn’t know about it until it was happening. There were no interview questions to uncover opportunities (user needs, pain points, desires…) and it was, in the end, a casual conversation with no focus and no particular insight was gained from it. There were a few typical mistakes:

• Leading questions

• Narrow and close-ended questions

• Asking the user what they think about the product or what they want us to build