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.
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.
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.
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
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?
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
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.
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.
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.
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.
Test Driven Development (TDD) is a wonderful way to ensure your team can write better software, faster. But, much like anything else that’s easy to learn but hard to master, the “three steps” for TDD are really six, and the practices represent a fundamental shift in how you build software.
That doesn’t happen overnight, or even over a 4-day TDD course.
One of the toughest parts of TDD is
realizing that when you try to apply it to an existing code-base for new
features, you run into pain. Lots of pain. That pain exists because the
existing software wasn’t written to be testable — it was written to
work, and probably written under a deadline. Since the team is on a
deadline, and Test Driven Development has ‘test’ in the name, we can
de-prioritize it, right? We’ll get to that later.
And so it goes. Team gets a new project,
Team doesn’t know how to develop software that is easily testable, and
team tries TDD, and the first time they run into a deadline, TDD goes
out the window.
It, as they say, happens.
I happen to know that TDD is very
well-suited for tight deadline situations — much more so than the
alternative (writing tests after the code is written, or not at all),
and part of my mission in helping teams build better software, faster is
to demonstrate that this is possible. But it requires changing how
developers think about a problem. It requires inverting what is useful
to what the business finds is useful.
You see, when faced with a new project, Developers will pick the technologies first. You’ve
very likely had a ‘Sprint 0’, where developers researched databases,
front-end frameworks, and technology stacks to figure out what they were
going to use to solve the problem, and you’ve also probably dealt with
stakeholders who see this as a necessary evil. It is an evil, but it’s
not necessary when you use TDD.
TDD is meant to flesh out what a system does, not how it does it. The tech stack is the how. The business cares about the what, and they want to see that ‘what’ as quickly as they can.
The whole purpose of TDD is to figure out the what as quickly as possible, and defer
decisions on the how for as long as possible, if not longer. You see,
TDD gives your business the confidence that your team is writing code
that solves your problem and shows demonstrable featuresquickly, all while defering the decision of ‘how’ until much later in the process.
also has the ancillary benefit to the development team of punting on
the decisions that can paint them into a corner until they know enough
to know whether or not they need to even paint that corner.
if you’re interested in an online course that teaches you and your team how to build software using TDD and avoid the problems I talk about above, sign up at course.doubleyourproductivity.io.
If you want a more personal touch, and you’re interested in a custom engagement where I help you and your team solve these problems uniquely to fit your business and culture, reach out and let’s chat.