Sourdough bread and ferraris

One of my favorite ancedotists, (that’s a word, right?), Josh Heyer, tweeted this recently, about people:

If you want sourdough, you don’t need to create bread yeast. You just need to arrange for conditions where it will thrive.

People are like this too. If you want collaboration, create an environment where it thrives. If you want violent anarchy, make it seem like a viable option.

Josh Heyer, aka Shog9, on cultivating culture

Besides being right, it got me to thinking about more productive teams and how that relates to Test Driven Development.

TDD by itself is sort of like a Ferrari engine sitting on blocks. It looks pretty but it’s not going to do you much good sitting on those blocks.

Some of the things that make the conditions right for TDD are:

  • Setting up Continuous Integration and Automated Builds
  • Architecture that takes TDD into account
  • Intra-team communication and pairing
  • Small-ish features

If these conditions are present, teams end up embracing TDD more naturally, and the success they receive from TDD multiplies.

When learning Test Driven Development, I missed out on all of these factors and only came to realize them after much trial and error and after being part of different kinds of teams, some of which embraced some of these principles, some that embraced all, and some that eschewed these principles. This is why my course on TDD takes all of these factors into account, and isn’t strictly about TDD. It’s about how to learn TDD and apply it successfully with your .NET Software project team. If that sort of thing interests you, sign up to receive updates on the course. As a special thank you, you’ll receive a subscriber’s only discount only available to… well. subscribers.​

Fighting the Framework

One of the things you’ll hear if you manage developers long enough (or if you’re a developer yourself) is someone will say, “I’m fighting the framework” or “It’s hard to do in the framework we’ve chosen”.

This usually because of an impedance mismatch – the same way taking American electrical products to Europe without buying one of those plug converter things is.

This bad boy can be yours for $29.69 from Home Depot. Don’t know if it’s worth it or not.

In its most basic form, it’s because the domain you’re solving a problem in thinks of its world differently than the framework you’re using does. Yes, any database can be used to power Wikipedia, but there’s one that fulfills the requirements wikipedia has the easiest.

As developers, when encounter this worldview mismatch, we’ll complain about it, without realizing our own responsibility to protect against that happening.

That’s where Test Driven Development comes in. One of its benefits is allowing you to push where the framework meets your code to an isolated place where it can’t do a whole lot of damage to your code, and where you can’t become dependent upon that framework and have to fight its idiosyncrasies.

In a world of conflicting worldviews, TDD provides a method to control that chaos, and allow your team to move faster. Real world examples of doing this are going to be in my course on TDD.

If learning how to control this chaos appeals to you, sign up to find out when the course is coming out, and to get a launch-day discount that won’t be available anywhere else.

Weight Loss Plans and TDD

At the risk of being treated as spam, we’re going to talk about the TDD problem just like I’m trying to do with weight loss.

After three kids and a lot of burnout, I’m about 30 pounds heavier than I want to be. I’m not concerned about this — I’ve been there before. I know what works when trying to lose weight. For me, doing it is the hard part. I know it’ll take a disciplined diet and consistent exercise, every day.

Weight Loss products tout “lose weight fast”, and they try to make it as simple as possible to get you hooked on their ‘system’. 2 shakes and a well-balanced meal is Slimfast’s promise, and TDD’s is Red, Green, Refactor.

The problem with weight loss plans (and Red, Green, Refactor) is that it over simplifies the problem and solution, and it doesn’t help you instill the habits you need to have to deliver projects on time and on budget.

Yes, you can take a 3-4 day class to help you learn TDD (I offer that), but without applying those lessons and creating habits on them, and having someone there to help you when you falter, it’s likely you will falter (that’s also why I offer monthly advisory retainers for teams who adopt TDD).

TDD is easy to learn. It’s hard to learn well, and it’s even harder to apply it to your codebase and constraints without help, and just like the two-shakes and a well-balanced meal, learning TDD as “red, green, refactor” oversimplifies the practices and experience needed to make you successful with it.

I offer in-person classes on TDD, customized for your team. I’m also putting together a video course for Test Driven Development for .NET Software project teams. If that interests you, sign up at https://course.doubleyourproductivity.io.

TDD: Insurance Or Faster Delivery?

I’ve been reading “Math with Bad Drawings” by Ben Orlin and am currently reading through the insurance portion — how insurance works, what makes it profitable, and the like. The gist (if you sell insurance professionally, forgive my butchering of your product) is that people pay insurance to protect them if Something Bad happens, and that Bad Thing is a thing that actuaries have spent their careers (or more) figuring out the probability of happening.

In short, if there’s a 1% chance a herd of cats will wreak havoc on a banana crop, you can buy Cats Destroying Bananas insurance for some price that will cost more than that 1% chance divided by their risk pool. That way, as long as Cats Destroying Bananas doesn’t become a regular occurrence, the insurance company will be profitable.


There’s probably a good reason insurance companies don’t provide software project insurance (if you know of a company that does, I would love to have more details), and that’s because we (the buyer of insurance) know that software projects fail regularly. We have more knowledge about software projects than your average insurance actuary, and that gives us a leg up.

The thing is, if we’re so ready and willing to buy software insurance because we know it’d pay out; why aren’t we equally likely to pay for training to ensure the project is delivered on time and on budget?

If you would pay 10% of your budget for insurance to compensate you if the project didn’t get delivered on time, would you also pay 10% of your budget to deliver it on time?

Using TDD to deliver a project from start to finish is a lot like buying software project insurance. It’s going to pay for itself from the buyer’s perspective. There are lots of reasons why teams don’t adopt TDD (not the least of which is that it’s not taught in a way that makes it conducive to every day use), but for the teams that adopt TDD and stick with it, they’ve purchased insurance that will net them a positive return.

Of course, I should note that “Go do TDD” is neither helpful nor going to make your team successful on its own. There are lots of ways to learn TDD and they all seem to avoid addressing the problems project teams face when trying TDD. I’m taking a different approach in my course. It’s geared towards solving the problems project teams face head-on. You can sign up to receive more details about the course and receive a subscriber’s only discount that won’t be available anywhere else by going to course.doubleyourproductivity.io.

Two Paths: Repetition or “Feel” ?

The pain in Test Driven Development (TDD) comes from developing software the same way you did before you found TDD.

That sounds like an odd statement to make, I know, but from my experience it’s on the mark.

Or, by way of analogies:

If you play golf, you’ll get that one of the hardest parts of the game is the ‘short game’. That part less than 100 yards from the pin, where finesse and control win over sheer power. You can get to the pin in 100 yards — the question is, can you get there accurately and repeatably.

Dave Pelz came up with a repeatable method for getting to the pin accurately. It’s called the ‘clock system’. Basically you practice with each short-game club and you hit 100 balls at 7:30, 9:00, 10:30 for each club, until you’ve dialed in the exact distance using the exact same swing each time. No ‘feel’, just raw numbers and repetition. Once you know how far each club goes at each clock position, you write those three numbers on a piece of paper and tape it to the shaft (this is permissible under USGA rules). And voila, you can go to any course, anywhere and as long as you know your distance from the pin, you’ll be able to get there, accurately.

This is a highly valuable system if you play golf regularly; but it represents a fundamental change in how you practice and play golf. You can’t go back to ‘feel’ after learning this method — it would be at cross purposes if you did (I tried to and it was super weird and I gave up ‘feel’ entirely).

TDD is the same way. Once you internalize that TDD represents a fundamental shift in how you solve problems, it’s difficult to go back. You can do it — sure,but once you do you’ll see those painful things you avoided by using TDD.

if you’re interested in an online course that teaches you and your team how to build complex software using TDD, sign up at course.doubleyourproductivity.io

If you want a more personal touch, or have a project where you’re not sure if TDD would be a good fit, reach out and let’s chat.