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.