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




Leave a Reply