When the Best Tool Isn’t, and Why a Growing Team Doesn’t Care

Kathy Sierra excellent post on When the “best tool for the job”… isn’t misses an important point. It’s not that she missed the point so much as she just didn’t go into it. But I think it deserves going into.

Many software developers become very attached to their favorite programming languages, methodologies, practices, and so forth. Checking the link-backs for my post “Twelve Benefits of Writing Unit Tests First” demonstrates this. One commenter on another blog even said he saw no value in reading the whole post, since it was specious and had no redeeming value. I took great joy in that comment, because it means I must be doing something right to push someone’s righteous buttons so accurately. Regardless, would test-first be the right tool for that programmer?

If you want to choose the best tool for the job, it’s not just about finding the tool with features that match up with the problem you’re trying to solve. You also have to take into account the people who will be using the tool. How well do they know it? How much do they like it. This latter may seem a silly parameter. But it does play into the equation. Any effective leader knows that it’s not enough to be right; you also have to get your people on-board. This is even one of the guiding principles of Alistair Cockburn’s Crystal Clear, that whatever practices you choose must be culturally relevent to the developers.

Here’s where Kathy stops. But we don’t have to stop here. Indeed, effective software teams never stop here. Witness Alistair’s second property of successful teams: reflective improvement. That is, we’re always looking to try new things and to validate them. If something doesn’t work, we know we don’t have to use it. We look for excuses to try new languages, new technologies, new practices. We shun excuses to avoid them. We are a growing team, not growing in numbers, but growing in maturity. Speaking of test-first, one commenter said you can’t try every new practice that comes down the pike. But a growing team can try almost every practice, one at a time. If you could try just one new practice a month, how many new practices could you try in a year? A growing team would never use this excuse to rule out any practice. They might decide to try something other than test-first to address the challenges they’re facing. But they wouldn’t just rule it out.

Similarly, a growing team would not write off the benefits of test-first, even if they did think the person touting those beneifts was high on drugs. Instead, they would ask whether test-first might address their situation. If so, they’d look for a way to try it. Maybe with a single module. Maybe with a sample project. If the experiment goes awry, how much effort would they lose? A few days? A week? Surely it’s worth that risk to find out whether this practice delivers on its promise and helps them do their job. Of course, before you can take that risk, you need to have slack in your schedule. You need to be able to burn time in order to try new things. Slack is where you grow.

But how does passion work into this? If we’re not passionate about a certain practice or programming language or framework, how can we use it? Even if we try it, won’t we sabotage our own efforts? After all, we can’t control what we’re passionate about, can we? To some extent, we can indeed control what we’re passionate about. Look at the passion of a growing team. A growing team is passionate about growth. And that means they will give new tools a fair chance. They might be skeptical. But because of their passion for growth, they will be able to set aside their skepticism. But they must choose to do so. They must choose to consider that maybe they’re wrong. They must choose to list what would need to happen to prove to them that they’re wrong. They must choose to test this list. They must choose to embrace the results and be excited to discover a new truth, to open up a new righteousness.

Growth is part of professionalism. Realistically, the members of a team will differ in their professionalism. Some will be more professional. Others will be less professional. After all, professionalism takes practice. Only some of them will be growing professionals. This may make it difficult—or impossible—to inject growth into a stagnant team. Reflective improvement itself may never be culturally appropriate, and the team may always be mediocre. Many growing professionals decide to go on to a new team that offers new challenges, rather than waiting for a stagnant team to catch up to them. For many people, this is the right course to take. For others, it’s more important to stick it out, take the leadership, and make a difference. And in a stagnant team, this will probably only happen over the long haul. It depends on your goals, your passions, and your strengths. And there we are back to choices.

Yes, it’s about passion. Inciting passion is one of the most powerful tools in the leader’s bag of tricks. Passion matters. It matters more than most managers want to admit. But decide whether you want to be a growing professional. Decide whether you want to be passionate about the tools or about the results. And if you choose the latter, know that you can indeed use the best tool for the job.