We’ve come across the problem of ensuring that developers continue writing tests for their code, and writing enough tests that we can actually ensure correct functionality.
We brought on several newer developers and are currently all working remotely, so I implemented a basic continuous deployment system using codeship to test and build our code before we allow pull requests to be merged, but sometimes when in a rush, one of us forgets to test a feature and it goes unnoticed because the tests pass.
My real interest is in opinions on what you might do in that situation. I’m a fairly new developer, let alone managing a team, and our transition to test driven development has been haphazard to say the least. We love the new style, but it is hard sometimes.
I don’t think you can ensure that the programmers write tests. You can require it, but at best, you get short-term compliance or work to rule. If they’re not doing this thing that you obviously believe they should do, then you have essentially two choices: mandate it as part of their job, which means firing them if they don’t do it; or exploring with them why they don’t just do it. Clearly, right now, they value not writing those tests over writing them.
Dale Emery’s model of motivation helps me a lot in these situations. It leads me to ask a bunch of questions, including these ones.
- Do they feel comfortable that they can write tests that they feel confident in?
- What bad things do they think will happen if they write tests?
- What good things do they believe won’t happen even if they write tests?
- What are they worried might happen if they write tests?
Explore Their Point of View
Whichever questions I ask them, I have one goal: to understand their point of view. I think about a time when I’ve not done the obviously good-for-me thing to remind myself how easy it is to fall into inaction, even in the face of an obvious potential improvement. The more I think about my own self-imposed obstacles to action, the more sensitive I am to their fear and anxiety, and the more likely I am to approach the situation with a genuine desire to help, rather than a need to impose my will or gratify my ego. (I think we’re all prone to this.) Having and showing genuine interest in their point of view seems to help a lot here.
Don’t Jump To a Solution
Many managers contact me for TDD training because they perceive that their programmers’ reticence to practise TDD lies in a lack of ability. Often, it even seems that way on the surface, because when we ask the programmers why they don’t do it, they say that they’re not sure what to do. This sounds like “we don’t know how to do it”, but after a few more questions and answers, I often find a different problem. They say “we don’t know how to do it”, but they mean “we’re not sure what to do, when, and we’re afraid to be seen getting that wrong”. A typical four-day course in TDD will not solve this problem. On the contrary, it runs the risk of setting up a direct confrontation between the programmers and the manager, because the manager expects the programmers to practise TDD confidently and consistently, even though the programmers still haven’t developed the judgment they need to feel comfortable practising TDD. This situation probably calls for an open discussion about the need to experiment, about making room for people to learn by doing (and failing), and a host of other issues that the group might not feel comfortable discussing.
This sounds like a trust problem to me, and not a TDD problem. So it goes.
I’ve never built trust without giving it away first. I’ve never built trust quickly, but rather I’ve always built it steadily over time. It often starts—once again—with expressing genuine interest in understanding the other people’s point of view and a willingness to help them get what they need from a situation, while also sharing what I need to get from the situation. The discussion might start like this.
I notice that we’re not writing tests for all our features. I’m worried that if we only write tests for some of our features, then we’re going to have false confidence in our code, and that seems like a recipe for anything form embarrassment to disaster. I need us to discuss this so that I can feel more settled about the situation. I’d like to help, if I can. Can we talk about what’s causing us not to write these tests?
If no-one’s willing to talk about it, then maybe there’s a much deeper trust problem. Or maybe they just don’t see the tests as useful because some other problem is the bottleneck. The distributed nature of the team means developing trust more slowly and with greater difficulty. The possibilities branch so much at this point, I can’t cover them all in a short article. I think that what matters most is opening the discussion, inviting others to join it, and treating everyone well. Start by trusting everyone to care about the problem and try to improve things, then see what happens.
For someone in this situation, you can read some books, starting with the ones I list below in the references, or you can push the fast-forward button by hiring me to help mediate the discussion or to coach you through doing it yourself. People who join my consulting circle get timely answers to their questions and can hire me for real-time coaching on an as-needed basis.
Dale Emery, “Motivation”. A model of motivation that I’ve used for years to help me understand why people don’t do what I think they ought to do… including me.
Patrick Lencioni, The Five Dysfunctions of a Team. A model of teamwork that has helped me diagnose and fix situations like the one described in this article.