Oh dear, my eyes hurt. I’ve just seen yet another bullshit post about TDD:

Let’s talk about TDD. Yeah. That one. Now before someone tries to Uncle Bob or Kent Beck me in the comments, let me clarify — I absolutely support writing unit tests. Lots of them. High coverage. Solid safety nets. No argument there. But TDD — the “tests-first, logic-later” doctrine — is something else. I've heard a lot of lofty, near-religious praise from its evangelists. “Write the test first, and the design will follow.” Sounds nice on a slide. In practice? Not so much. In my entire career, I’ve met exactly one person who actually practiced TDD consistently. And guess what? Even he admitted he had to force himself into it like it’s a gym routine he secretly hates. Here’s my beef: TDD shifts your focus to the wrong thing. It idolizes the test — not the system, not the domain, not the architecture. You're supposed to build a well-structured, modular system… but instead you're writing a failing test for a method you just imagined into existence, praying that this micro-step will magically evolve into a beautiful system. Spoiler: it doesn’t. TDD doesn’t encourage thinking in terms of cohesion, coupling, design boundaries, or long-term maintainability. Instead, it traps you in a rabbit hole of tiny, myopic tasks. “One failing test at a time.” Great. Now you have a bunch of tests for methods that shouldn't even exist in a sane design. What would actually help? Taking a step back. Thinking in modules. Understanding business flows. Designing clear, purposeful abstractions. Not handcuffing your brain to a red-green-refactor treadmill and hoping architectural clarity falls from the sky. Sorry (not sorry), but making TDD a mandatory ritual is like solving architecture with duct tape — just with more IDE shortcuts. Curious to hear from folks who’ve actually built systems, not just pet projects and conference demos.

One of the most honest and revealing questions any leader can ask themselves is: how much do I truly trust the people I lead? Trust isn’t just about delegation or believing in someone’s abilities. It’s about empowering others to make meaningful decisions.

Imagine you’re responsible for a budget. Would you feel comfortable allocating a portion of it directly to your team, giving them the autonomy to pursue initiatives they believe in? Would you trust that, within the strategic goals and constraints of the organisation, they would use those resources wisely and in alignment with the broader mission?

I’m always baffled by those who argue that TDD shouldn’t be applied “religiously,” “completely,” or who imagine some kind of “pure TDD” in contrast to a more pragmatic version.

It’s as if they’re trying to make up for a lack of understanding by practicing a watered-down version of TDD, dismissing anything more rigorous as impractical purism.

They go on complaining about the lack of resources for applying TDD to large projects, as if some special recipe exists for that.

Software is not manufacturing. Fund teams, not projects.

When people trained in traditional project management (e.g. construction) step into the world of software delivery, they often face a difficult shift.

In those industries, scope is fixed, timelines are tightly managed, and costs are estimated with precision. Deviations are treated as problems to be avoided.

Software, however, is a different kind of work. It evolves as you build it. Discovery happens along the way. Trying to apply rigid planning models to a dynamic environment creates tension, particularly when it comes to discussing estimates and budgets.

In virtually every organisation I’ve worked with, teams have been eager to experiment. The desire to learn, improve and try new approaches is almost always there. What’s often missing is the environment that allows it.

Software teams must be able to experiment continuously. This is not a luxury. It is a fundamental requirement for solving complex problems and adapting to change.

But experimentation is only possible when teams have autonomy. And autonomy stems from freedom and trust.

Weekend reflection: it’s surprisingly difficult to grasp how an organisation (especially a large one) truly works.

Every company begins as a small group of people with fluid dynamics. Early on, structure follows culture. Norms are shaped by how people collaborate, make decisions, and navigate ambiguity together. But then something shifts. Power dynamics begin to form, roles become formalised, processes start to solidify. Structure takes hold, and gradually, culture starts to follow it.