Getting Past Shu
It’s pretty common in agile books to come across the concept of shu-ha-ri, the idea that beginners learn differently than intermediates who learn differently than experts. Beginners, they say, need to just go through the drills, sort of unquestioningly, just working on doing each step without worrying too much about whether they understand the steps or not. In an agile book, this is usually an admonition to the new agile team to trust that the process works.
The process does work, of course, especially with a green field project. But what about real projects, in the real and messy world of brown field projects? The problem here is that when someone is faced with a 500 line long code block that nests 7 levels deep, it isn’t always obvious where to start writing tests. And there is no process to trust at that point, not exactly. There’s a requirement to practice TDD, which means they need to test this mammoth method before they alter it. And there are new coding guidelines that point at these gargantuan statements and say, essentially, “Don’t do that.”
Now, I know that there are patterns to follow and books to read. There are books on refactoring into patterns and on design patterns and on refactoring and on legacy code. The books provide excellent advice, but they don’t provide the grit and determination that a coder needs to start dealing with one of these monster methods. Grit and determination are occasionally undervalued as commodities in the coding world. In my current role as an agile coach, this problem is easy to recognize. For example, in a recent retrospective for one team I was coaching, a developer said she was confused about how to “refactor fearlessly.” In other words, where to find the grit and determination to refactor a nasty piece of code.
If you are the tech lead or dev manager for a team that is instituting TDD, this grit and determination has to come from you. For one thing, you need to accept that your team’s velocity is going to take an initial hit. This is natural and expected, not because TDD is slow, but because you are asking people to learn a new skill in a place where experts fear to tread, and these novices are going to tread slowly. Someone, possibly you, has not taken care of this code base, has allowed technical debt to accumulate to a point where safely refactoring the code requires enormous care and delicacy. Someone, possibly you, has been artificially inflating their velocity up to this point, living on tomorrow’s time by accumulating more and more technical debt in the form of monster methods, tight coupling, misplaced business logic, and a host of other code smells. Now that tomorrow is here, you have to pay off that debt or you’re going to lose the metaphorical house.
Of course, if you’re at this point in the life of your software, your velocity is starting to drop anyway. Features that used to take hours to implement are starting to take days, as people wander through the weeds and try to find out where to put them. Competing styles and patterns are cropping up, confusing new developers and angering the veterans. Bad decisions are being piled on bad decisions as your team desperately tries to keep up with their performance from previous cycles. Your developers have grit and determination, but they’re channeling all of it into just shipping product, rather than building quality.
You feel like you are past ‘shu’, like beginners can’t use TDD in this environment. The pressure is on and the problems are deep, and beginners need a lot of time to come to grips with this situation. You know how to write code the old way, and so far you’ve been able to ship code, so you think it is easier to just keep developing without tests. You know that if you institute TDD on your team, you are going to have a lot of extra work on your plate, because you have to stay ahead of the team on TDD and you have to explain why you aren’t shipping code as fast as you used to.
It’s time to get past ‘shu’. Not the beginners framework of TDD, you still need to learn that, to follow the forms and rules and painstakingly figure out how to apply known approaches to your problems. No, you need to get past the ‘shu’ of your current job. You no longer are free to follow the forms and just do the expected. It’s time to make innovations, to break out of your comfort zone and make decisions.
It’s time to take up the ‘lead’ part of ‘lead developer’ and lead your team.