Following Roy Osherove’s talk at Innovative TechTalks in October, we’ve learned that many developers have already tried test-driven development (TDD). Some have failed, others have concluded that it’s just not worth the effort. In theory, it’s a good practice but somehow there’s never enough time to use it properly.
“When you do test driven development, what happens is that you end up writing more tests than code. You might end up with 50% or 60% of your code being tests. That means that time might double, especially if you lack experience.” – Roy Osherove
Understanding test-driven development (TDD)
Test-driven development, or TDD, is a pioneering software development approach where developers perform tests before writing the code necessary to complete the test. Following this step, the code has to be refactored to pass the test. In layman’s terms, when adopting TDD you write a minimum amount of code, and then you refactor. The problem is, it’s easier said than done.
When you write in a test-driven manner, you are a customer of your software and you realize that your API may be faulty, or that your design is not usable enough; and you will find a way to change it because your tests tell you to do that. One of the greatest things about TDD is that you can take a practice and do it regardless of the methodology that you use, because it’s something that connects you and your computer.
According to Roy, “You, as a developer, can decide whether or not to do TDD. Just like you, as a developer, can decide to do debugging. No one tells you when to debug your code, right? It’s your personal decision because the choice comes from within, not from the outside.”
Adopting TDD
One of the main benefits of test-driven development is that it enables software developers to build testable and maintainable code. By adopting TDD, you validate the code earlier and you avoid wasting valuable development resources on building faulty functionalities. It goes hand in hand with unit testing because it’s a certified way of knowing you are creating testable code.
However, adopting TDD is a never-ending journey in many companies because if you want to start changing things, first you have to start understanding people. “Software is about people collaborating or not collaborating. Every software problem is a people problem.” If you can’t figure out how to understand the people you’re working with or working for, you’ll get stuck in a rut.
With TDD, just like with most things in life, the only way to understand why someone is not doing something is by talking to them. Very few software developers adhere to the raw vision of test-driven development because of several reasons. First, software development involves connecting legacy code, integrating libraries, and extending existing functionalities. That being said, TDD may not be practical for those that lack time to write new code.
Second, if you are a team leader and you want your team to do unit testing, they might not want to do it because they’re afraid. Things will take longer because you need to change the estimates. One of the scariest things that you might have to do is go to your manager and say “Hey, you know that thing I said it will take a week? Well, it won’t take a week, it will take two.” How do you change that? You have to change the system and allow longer estimates.
What prevents developers from adopting TDD?
The promise of TDD is rooted in the principle of lean development. Although it enables software developers to produce testable, maintainable, and efficient code, real world conditions prevents TDD from being adopted by team leaders. According to Roy, “what prevents a person from doing TDD is the system which doesn’t allow automated deploys and roll-backs. Because in a roll-back, you could go back to the code and fix it with unit testing. Without roll-backs, automatically you’d have to fix bugs in production, do patches to ugly code to make things work with no testing, no continuity, and no scalability.”
He emphasizes that most software teams are in “survival mode”. Survival mode is the state of the developer who wants to learn, but doesn’t have TIME. The only mode to get out of survival mode and into the learning mode is by MAKING TIME. For a team leader, going to their manager to ask about changing estimates is scary. “But scary is great, because when you’re uncomfortable doing something it means you’re out of your comfort zone and ready to learn something new.” As a team leader, learning something new is your job, and teaching something new to your team is also your job. If you are able to take risks, then your team will also be able to take risks.
Good management is a really tough job because as a team leader open about TDD, you’re the one who has to ask for things, confront about ideas, look reality in the eye, and actually do something about it. That’s true leadership, but it’s really scary. The worst thing that can happen is that you’ll get a “NO”, which will help you learn how to ask better.
