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.
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.