Consider framing stories as learning activities. Instead of “as a … I need to … such that …” try “as <team> we will learn how to … such that …” Too often stories turn out to be wrong in subtle ways which make them hard to close. If the emphasis is on learning is clearer

All good design is testable but not all testable design is good. Low tests coverage is always bad but high tests coverage is not always good. What other one way correlations have you encountered?

Lately I’ve found my self writing more ADRs and KDRs than code. Funny how everything I’ve learnt about small steps and refactoring is a 100% transferable skill

I wish I could write tests for prose. assert_<some_point>_is_expressed_in_<some>_way So that I could apply TDD Could I get my AI to do this somehow?

The most human thing about AI coding agents is that they really struggle with working in small steps

Maybe the killer feature of AI for programming is making the cost of mapping layers effectively zero

He still not able to get real value out of agents. The edit mode in copilot still the only way I can keep control

Trying to take agents seriously. By default it is easy to eager to make changes. Trying to get it to follow a plan in small tiny steps is way too hard

The future of enterprise software development is test-writing

Augmented coding is amazing. Now I just feel silly for being this late to the party. More designing, more experimentation, less bug hunting and much better tests!

The augmented coding flow really changes the economics of making changes. Bigger experiments can be to cheaper and faster. Making it both productive and fun

Lately I’ve been experimenting more seriously with ai. I’ve yet to give any value in agents BUT the edit mode on copilot (where you select which files to include) + TDD has me extremely excited

Complexity is managed not only by **what** we build but also by **how** we build it

I’m currently trying to teach a small group of experienced engineers how to work in small steps. Turns out that I had completely forgotten how some (most?) engineers work… everything everywhere all at once

Okay, first attempt at teaching engineers how to be agile: Lesson 1: work in smaller steps

I’ve reached a point in my career where I need to teach XP to others. It is incredibly difficult. Some engineers are so cynical that they genuinely think TDD is a hoax, TBD is unprofessional, small steps are impossible. How do you deal with this?

How on earth do you teach software engineers to work in small steps?!

How are you planning your sprints/iterations?

When in doubt whip Art of Agile 2nd edition by James Shore out  www.amazon.com/Art-Agile-De...

Good architecture is a trailing (not leading) indicator of a healthy project

Biggest testing antipattern: testing for the sake of testing

Communicating clearly about software development is vey difficult. The most visible aspects are not necessarily the most important. A disproportional amount of time is spent on: languages, story points, code reviews, to-be architecture, backlogs, refinements, planning

Arlo Belshees blog is amazing! Some of these posts are approaching 15 years but haven’t aged a day.

I find it really frustrating to see these misguided arguments against TDD being presented with such self-congratulation. youtu.be/kJWsFWY25GA

What is a good resource for learning C#? Not talking about syntax or Hello World, but “modern” style of it. Where can I learn to *get* modern C#?

Just read the comment section on Valentina Jemuovics post “Without TDD, your KEY DEVELOPER is the ONLY person who knows the details about the system behavior”. It’s easy to forget just how “offensive” TDD is to some people.

Why is TDD so effective? I often find myself completely caught off guard by how effortlessly it guides design. Whenever a behavior becomes hard to tests it’s (almost) always an issue with the design. It changes the game from “creating a solution” to “describing a problem”

Little did he know that by learning TDD, he had set himself on a path that would eventually lead to an obsession with functional programming…

Under-engineering is a much bigger problem than over engineering. But I think the terms aren’t well defined. Over-engineering is solving problems you don’t have (yet). Premature generalization/optimization, adding code in anticipation of requirements. 1/2

Was interviewing a candidate today and asked if they had any experience with TDD. The answer was no since they had never worked at a company where it’s was allowed… Imagine thinking that you would have to ask? And then being told no.

In the era of generative AI, the most crucial skill for any developer is testing

I love Fred Brooks and Aristoteles as much as anyone but I feel like “non-essential” would have convey his point better than “accidental”

There is a fun little parallel between Poppers “who should rule” critique of politics and @davefarley77.bsky.social s “quality _is_ changeability”.

More than anything else, testing is a tool for thinking

Hard truth: your big “to be” architecture diagram is actively impeding healthy progress

“Unit Testing Principles, Practices, and Patterns” by Vladimir Khorikov is on another level!

Optimizing for ease of change has the weird side-effect of removing emotional attachment to the code. It’s not that you don’t care but it’s just understood that it is temporary

It is more expensive to get rid of complexity than to avoid it

The AI can only generate code, not insight

The book that I recommend the most is still James Shore’s “The art of agile development” (www.jamesshore.com/v2/books/aoad2)

Perhaps the most effective, yet counterintuitive, practice of software development is slowing down

- work on less things - work in smaller batches - run the tests after each change - integrate continuously - 80 % refactoring 20% new features - new code is a response to a failing tests

Controversial take: I really like GitHub Actions

Jira is the lead piping of the software industry. It’s good to be organized around work but Jiras opinionated approach drives people mad

Writing code which is easy to change is nowhere near as hard as some people think

When I started doing TDD I was still stuck in an implementation oriented worldview. I would imagine what the solution should look like and then write the tests for that solution. Over time I gradually learned to let go this habit and focus on the tests and making sure they are as clear as possible

IME there is plenty of value in using AI in software development (TDD with copilot is is great!). But I worry that it will push more devs towards a “manufacturing” mindset of development where the focus is on finishing rather than understanding

Newly written code that has never been executed by tests or otherwise is pure conjecture. We have no good reason to expect it to work and even less reason to expect it to do what it should

So… how do you develop GitHub actions? Is there a good way to do apply a tdd-ish workflow? I’ve found some promising tools like github.com/nektos/act but nothing about specific development practices

Fundamentally software development is about “cratering knowledge”. What is the right problems to solve? What is the right decomposition of this problem etc. Being agile means applying Popperian critical rationalism in order to build this knowledge