Converting a Team to TDD — Series — Part 1
The company I work for as a consultant is a consulting company based in Los Angeles. Prior to starting this company, a couple of our founders were on the team that created the first American Idol website while at Fox.
We have a range of clients, mostly .coms. Some big, some new. One of them is actually a startup run by Puff Daddy’s ex-CFO! Another was a robotics company in CA building Kuri. Pretty neat projects we’re on I have to say.
Well, I’ve been recently asked by my CTO to get the team into Test Driven Development. At first I thought “year sure, I’ve heard this before”. But when he said he wanted to stop everyone cold turkey and to have them start practicing Test First, I realized he was serious about it. But I urged him to follow my advice by reading here which he did. If you haven’t read that blog post by me, read that first. The idea is to flip one developer at a time.
Is This Possible?
Is it possible to convert a team to Extreme Programming or a subset thereof? Sure! It’s happening more and more, and that pace is increasing.
Companies such as Pivotal, ThoughtBot, 8th Light, ThoughtWorks, and many more are doing this all the time successfully. Check out WeDoTDD.com for more on that!
One Developer at a Time
He liked the idea of flipping one developer at a time by pairing. That way velocity doesn’t take a gigantic hit. I said exactly! Plus I said it just won’t work cold turkey across the board as a mandate all at once anyway.
We have to be sure developers learn it, and learn how to do it right or it’s not going to be a success. I said that’s how I learned; I learned by pairing with some folks from 8th Light for 4–5 months. It took me 4–5 months of pairing every day with them to even feel like I was able to start doing it on my own. If I hadn’t done that, I would just be hitting the same walls that everyone hits and possibly saying “TDD is impossible” like you hear people say. By pairing with them I shaved off probably 2–3 years of pain, and I learned how to start off doing it right.
You have to invest in pair programming if you want to get people into TDD. Self teaching it is very hard IMO and just takes a hell of a longer time getting there. Plus you have to know how to write good tests and how to write code to keep it simple using Clean Code, concepts an practices from Four Rules of Simple Design, SOLID Principles, etc. They all go together for successful TDD.
The only issue I have is that I’ve only been given one sprint per developer. That’s not enough I told him. Not even close to enough. I know that I really need 2 months per developer. TDD takes pairing with someone for a couple months. And front-end TDD is even harder. 2 months might sound ridiculous, but consider how many teams do it wrong and then they go and bitch how they got burnt by it or that they “can’t do it”. It’s because they lack the mentoring, discipline, and practice to get themselves into the position to be able to do that on their own in the first place.
But I wasn’t about to argue nor did I really have a choice in the matter. I’ve been given this opportunity and top down initiative to pair which is rare. I enjoy sharing what I know, and really care about the team’s success in it. So I wasn’t going to pass that up. It is an opportunity to get some people’s feet wet and show them what TDD can do for them.
TDD Steps
Keep in mind this is a team which didn’t test. When I got here almost a year ago, I think I saw maybe 20 tests on one of our projects, all broken, but that was it. The code was very coupled and almost all those tests were invaluable and so I just blew them away; they were in the way, broken, not reliable, not repeatable, and had no good DSL to follow.
They didn’t really know how to test TBH and as usual dished out excuses as well as treated testing as a “feature” and pushed it off into never-land. The team was even just a few months ago told not to write tests by one of our leads which for me does not go over well and I do not abide by. The reason given by our lead was that the codebase was such a mess, that adding tests he thought was risky.
The problem with a mandate like that cross team is that to developers who practice TDD, a mandate like that doesn’t apply. Because TDD is how we guide design of code; it’s a cycle we perform all day long every few minutes, so for us, it’s not an option; It’s a tool we rely on, and it’s our right to do so. So that mandate does not jive with TDD’ists, it just doesn’t even make sense. If the rest of the team doesn’t want to fine, but choosing to TDD is an individual choice and right. It’s a tool that we’re not going to stop using, because it’s the way we work best.
I’ve been TDD’ing here for about a year while the rest of the team did not. One of our codebases was such a mess that it needed to be decoupled to be able to TDD effectively on it. Luckily for the most part I‘ve been on a couple greenfield projects for a couple clients where I did TDD 100% on the code I produced. I was also put on a codebase that was a mess for a few months and found it hard to TDD on because the code was so tangled that there was no way to really create isolated unit tests without pulling stuff apart which was painful.
In December, 2017, our CTO sent out a list of topics to talk about in an up-coming “Dev Workshop” to discuss. It wasn’t really a workshop but more as to introduce the new goals for the team going forward and to sorta lightly talk about them and come out with action items.
So he sent the list in an email to the team which included goals of reducing cycle time, reducing defects, improving predictability, and having ownership of our code. In the ownership of code section, included a mention of Software Craftsmanship in his document.
And obviously TDD was in the list and after our CTO had done some research this was his little “TDD step list”:
- Write the test, then implement.
- If editing uncovered code, cover it!
- Writing unit tests first will lead to decoupling
- Refactor as you test, not after a build is released
- If your IDE supports it, have the test suite run on every save to find side effects faster
Great list. But Lets Review That Again
I give him a huge thumbs up for demanding better disciplines and reading up on TDD. Most CTOs don’t. And this is a pretty important big step forward for the team. And it’s what more CTOs should be demanding. Those are the CTOs I love working for.
More and more CTOs are starting to see that XP Practices, especially TDD and pair programming, will really turn around how they write software and truly change a culture for the better on a development team.
Back to our CTO’s rough “TDD list”, as there are a few things I wanted to make note of and sort of clear up a bit more.
- Write the test, then implement
We’re missing the blue step here. If you just do write a test then implement it, that’s not TDD. Refactoring is just as important as red and green steps. They’re all important equally. You don’t skip refactoring or you totally lose the benefit of Test Driven Development
- If editing uncovered code, cover it!
Our CTO was more referring to a big mess of code we had on one of our projects that was grinding the team literally to a halt. The team complained about that to him as well. But really also talking in general as well. This falls into the realm of “The Boyscout Rule” so for code that means “Keeping the Campground Cleaner Than you Found it”, an idea originally brought to us by the Clean Code Book (or watch videos at cleancoders.com) by Uncle Bob Martin.
Uncle Bob talks about every time you check in some code, make that code just a little cleaner than you found it. If everyone on the team did this, the code would keep improving over time, not rotting. So adding tests around code that’s not covered I put as part of this as well.
- Writing unit tests first will lead to decoupling
This is true….if you understand how to TDD properly. This works if we’re making sure we only write enough code to make a test pass. And if we know what tests to write. And if we know how to derive the tests off of requirements. And if we know how to keep our tests very small. And if we know how to keep code simple in terms of test and production design.
If you are aware of those and keep doing that, then sure, our tests will put pressure on our design because the next test will be hard to write if we don’t decouple code as we go. You’ll find that as you go, you won’t be able to write the next test if the production code is coupled too much
- Refactor as you test, not after a build is released
Well this is obvious. If you’re practicing TDD, you must to do this, you don’t have a choice; you don’t skip that. It’s core to the TDD cycle. You do this every few minutes. That’s what TDD is, refactoring every few minutes as part of the definition of doing TDD.
Red | Green | Blue is a tight cycle. They always go together. You do them every few minutes. And none of those steps are optional. That’s called being disciplined…absolutely necessary if you want to practice Test Driven Development. If you’re not doing all three religiously, you’re NOT doing TDD…period. There is no debate on this. If you’re going to be half assed on that, just forget trying TDD then and go back to your merry way of creating messes with no tests. If you want to talk the talk, then you truly have to walk the walk with adopting and practicing TDD. And your project managers better understand this as well if they complain you’re refactoring. They need to be sat down and explained what TDD is and told to leave the developers alone to do their job. It’s not a Project Manager’s decision whether you refactor. When you TDD, you refactor all the time as you go. This is never optional.
- If your IDE supports it, have the test suite run on every save to find side effects faster
This doesn’t really make any sense. It doesn’t matter if you’re using an IDE or not. You’ll be able to run tests whether it’s from the command-line, or if you are using an IDE either from the command-line or say for example WebStorm’s or IntelliJ’s awesome built-in test runner. Either way there’s no obstacle in being able to continuously run tests locally as you code and practice Test Driven Development. When developers practice TDD they rely on a fast feedback loop. And that loop includes running tests every few minutes.
Time to Pair!
He did say that some developers will be skeptical because they need to see TDD to believe in it. I agreed and said that’s cool, well..lets get started!
He wanted me to start teaching TDD on the codebase that was a tangled mess, not on a nice clean greenfield project :). I knew this was going to be challenging because I had to not only figure out how to detangle the areas of code we TDD in driven by feature, but also had to teach someone TDD while we do that.
You can’t TDD if you are not writing isolated unit tests but to do so over an existing tangled mess of code means either adopting a strangler pattern which is putting a new facade over the mess…or to decouple (refactor) the existing mess in the area of code you’re modifying little by little as we go. Either way takes time.
So I knew it was going to be quite a challenge and that TDD was not going to be going fast at first for people especially if we needed to decouple a huge mess as we try to TDD on it. Even with greenfield code, code which is not so tangled, for someone to learn TDD, it starts out slow for them. But again it’s more important for them to learn how to do it, not speed at this point. Speed comes with discipline and practice.
The first take-way from the meeting was for our Project Manager to find a developer who’d like to volunteer to be the first to pair with me. I’d pair with that developer for a sprint.
Keep in mind our team has a lot of remote developers. Some are in Los Angeles but a good number are remote. So I’ll be remote pairing with everyone using Screen Hero over Slack since I live in Chicago.
Over the next couple months, I’ll blog about each developer I paired with, their existing experience level with tests, what we worked on, how it went, successes and failures, and thoughts as we go through this.
