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

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

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

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.

TDD Aligns Solving Problems with Business feedback

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 features quickly, all while defering the decision of ‘how’ until much later in the process.

This 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

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.