Hey all. I’m super excited to announce the launch of my new book.
It’s Lean TDD: TDD Without the Waste.
That link in the last sentence is a link to leantdd.com.
There you’ll find links to all the places you can read or listen to it.
Right now, it’s available at:
- Amazon as a paperback
- Amazon as an ebook
- Audible as an audio book
- Other platforms to come later …
In the next few months, it will get onto other platforms. I’ve already had requests for Kobo, and just raw files sold through my site, and I’d also like to get it onto library platforms.
If you want to know when other platforms open up, jump on the newsletter.
Ok. Now what is this book about?
It’s about 100 pages.
Yes, that was a dad joke. But also I do want to point out that it’s not big. You can listen to it in about 2 hours or less. You can read it real fast. You can throw the paperback in a carry on and it won’t take up much space.
But seriously, it’s about how I do TDD. And it’s a bit different than how I’ve seen TDD taught elsewhere. It’s also a crash course in a bunch of TDD and Lean concepts.
Actually, you should probably just read the first chapter, which is available at leantdd.com, but I’ll grab a bit of the first chapter and paste it here.
Here goes…
Why Lean TDD?
TDD is awesome. That’s a good place to start.
I learned about Test Driven Development early in my career as a software engineer. I’d like to say that I saw an immediate productivity boost. But the benefits were more gradual. Learning to effectively include automated testing into the software development process definitely did have massive positive effects, but the transformation wasn’t quick, and it required incorporating other practices to get the full benefit.
The general idea of TDD immediately made sense to me. I had by then been on a handful of development teams and had been through several software projects. These were all in the domain of RF and communication test instruments and systems. All of the projects followed some form of the traditional SDLC, Software Development Life Cycle, with most of the QA happening at the end of the cycle. But testing at the end causes problems.
Problems like not knowing how long the test and fix phase is going to be, having schedule slips, having to quickly rewrite a part of the system, and just generally a stressful not-fun time at the end of each development cycle.
When QA starts testing, they find issues. That’s expected. Then bug reports are filed. The reports are triaged and prioritized and assigned. The reports need to be evaluated to decide if the problem is in the test code or the production code. Any fixes change the code, so we have to retest. And the fix might break something else, and that gets reported. Rinse, repeat.
I remember thinking as a developer that a lot of that process and pain could be eliminated if we had the tests available during development. And it does improve things.
A big speedup happens when the development team can run the failing tests when diagnosing and fixing the issue. Even better if they can run the whole suite. That keeps the whack-a-mole of fixes causing other problems within the development team and saves handoff time.
Even more speedup happens when the development team is involved in defining and writing the tests, and that brings us to Test Driven Development.
TDD seems reasonable. We can start writing tests at the same time as the production code. And whenever we get a test to pass, we make sure we don’t muck it up during future feature development.
That’s kinda what I thought TDD was when I first heard of it. But that’s not what most people learn when they learn TDD. Most versions of TDD are not about those “make sure the system works” tests and are more focused on individual developer “did my code do what I thought it should do” tests. This ends up causing a duplication of effort between developer tests and system validation tests.
There are a couple of exceptions. BDD, Behavior Driven Development, and ATDD, Acceptance Test Driven Development, focus more on the system verification tests. However, proponents of ATDD and BDD still frequently recommend more traditional forms of TDD for the developer focused tests. So we still have the duplication of effort.
Lean TDD aims to remove this duplication of test effort. And while we’re at it, we’ll try to remove any other wasted effort we find.
To build Lean TDD, I’ve pulled ideas from Test Driven Development by Example, Lean Software Development, The Pragmatic Programmer, and tons of other great books and articles to create a software philosophy and practice of continuous improvement, adaptable processes, clear communication, early feedback, and, at the center of it all, incorporating automated tests into the entire software development workflow.
Lean TDD is a very effective, efficient form of TDD that translates well to all kinds of software development. It works with large teams down to solo developers.
This book is about Lean TDD, the flavor of TDD that has worked best for me. But I think the reason it makes sense to me is also due to all of the study I’ve done in other practices. The ideas from many flavors of TDD and the lessons from Lean in finding and reducing waste all come together to form Lean TDD. I want to give you a crash course in that background study. That way, even if you don’t follow my logic and come to my same conclusion that Lean TDD is the obvious winner, you’ll have enough of a head start on other material to come up with what’s best for you.
…
That’s just the first couple of pages.
Is this relevant for coding with AI?
Yes!
Let’s grab another chunk of chapter 1 that addresses that question.
The concepts in the book will work in lots of work environments:
- if you are new to coding or an experienced developer
- if you are on a team or a solo developer
- if the development team is doing all the testing, or if you have both developers and test engineers
- if you are using AI coding agents to help with production code, test code, both, or neither
That last point matters more than ever. AI can write code, and even write tests, faster than any of us. But someone still has to decide what “correct” means, and someone still has to trust the result enough to ship it. Lean TDD gives you that framework, whether the code in front of you came from a teammate, from your own fingers, or from an AI agent.
There is a chapter dedicated to this AI discussion.
Please check out LeanTDD.com for the rest of the first chapter and links to everywhere the book is available.