Using TDD to Break Through 'Paralysis by Analysis'
As a high-performing software professional, there may be times in your career where your mind freezes as you try to anticipate every disaster that might happen. It may start to take you longer to deliver your high-quality code.
Younger “rock stars” spit out code while you think/worry about design, maintainability, dependency management, modularity etc. Management seems to only see one thing: speed and your lack of it.
I’d like to offer a strategy for using TDD to streamline your design process.
I know what you’re saying… *“but TDD only adds overhead!”… “TDD is a waste of time”… “good coders don’t need to test”… “there’s no way testing could make me faster“*
It can make you faster if you’re struggling with design decisions.
The rhythm of TDD, as defined by Kent Beck in Test Driven Development: By Example, involves:
- Quickly add a test.
- Run all the tests and see the new one fail.
- Make a little change.
- Run all tests and see them all succeed.
- Refactor to remove duplication (Beck, 2)
This rhythm has advantages on its own, however, it’s not the only way to view TDD in the context of the design of an application.
Enter the GOOS
GOOS is short for a book called Growing Object Oriented Software Guided by Tests by Steve Freeman and Nat Pryce.
GOOS is centered around the feedback that developers need in the development process and how TDD can give you this feedback.
We need feedback in order to observe the effects of a decision we make in the development process. There are 2 levels of feedback that we can build through tests:
The internal feedback loop:
“focused on the technical detail: what a unit of code does, whether it integrates with the rest of the system.” (Freeman, 4)
The external feedback loop:
“focused on the organization and the team, whether the application serves its users’ needs, whether the team is as effective as it could be.” (Freeman, 4)
So why would I offer GOOS to you as a developer who feels “paralysis by analysis”?
Because you have been around long enough to know the many options and considerations for the design of your application. You have learned, over time, what high-quality code looks like.
“We find that the effort of writing a test first also gives us rapid feedback about the quality of our design ideas - that making code accessible for testing often drives it towards being cleaner and more modular” (Freeman, 5)
Practicing TDD with a focus on getting fast feedback about decisions can help you make better decisions faster.
Early Uncertainty
You might also feel like your productivity is hurting because you want to be 100% certain about your architectural decisions up-front. This certainty is difficult, if not impossible. GOOS offers a way to curtail this uncertainty early through building and testing a “walking skeleton”.
A walking skeleton is “is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end” (Freeman, 32). Wait, deploy!?!?… yes, deploy the project before you’ve even started writing code.
The purpose of a walking skeleton is to establish the structure of the application in a way that you can make some essential decisions before you write code. By focusing on automation early, you can begin getting feedback on the development process early.
Since building a walking skeleton requires establishing infrastructure and answering a lot of questions up-front, it helps you sort out some of that design uncertainty and chaos that can show up later in the project. This chaos is what your experience has taught you to fear, and what may be slowing you down.
So try taking a look at TDD from a different angle than just bug prevention. It might help you get out of the gate quicker when you’re struggling with balancing design quality and output in your work. And make sure you sign up for my newsletter for my latest articles, right to your inbox!
Related Posts: