Happy Friday!

Guess what? I'm doing a talk on April 8th, and I'd love for you to attend! My talk is going to try to tackle how to introduce TDD to a non-technical person.

You should attend, it's free!

One of the reasons I chose to talk on this subject is that I've come to appreciate test-driven development as one of the most impactful practices I know and unfortunately it is ignored by most of the software industry. This avoidance isn't proof that the technique is bad, but more that it goes against intuition, years of habit, and most dangerously, an industry that favors speed above everything else.

Woody Zuill, who is credited with the creation of Mob/Ensemble programming wrote a LinkedIn post that summarized this elegantly. The post is about how early in his career he was told not to do TDD because it took too long.

The reality is that not all effort is equal, and the way most developers work is full of friction and lost time that TDD directly addresses and is as fast as or faster than what I'll call traditional or legacy development (If that stings, I did it right).

Now, for people who have never done TDD, this seems insane. The truth i,s you can't really think your way through TDD without doing it. This is sort of like how lots of groups think deploying software every sprint or more frequently is impossible or insane. You have to get over it and do the work. Then suddenly you can't imagine ever going back.

So, most technical folks think TDD is insane, so they'll never even try it. It takes someone like me or a much larger group of non-technical folks to nudge the tech community to take a leap of faith and see what happens. In my view, leaving things like TDD is like building a car manufacturing plant and hoping the workers on the line figure out they can use their hands instead of their feet to install things.

That's the pitch and a little behind the scenes on why I'm choosing this topic. Come check out the talk, I'd love to hear what you think.

Sincerely,

Ryan