Last Thursday, Januari 19, I gave a short talk at ArrowsGroup’s Agile Evangelists event in Amsterdam. Michiel de Vries was the other speaker, talking about the role of Trust in Agile adoptions. On my recommendation the organisers had changed the format of the evening to include two Open Space Technology sessions, right after each 20 minute talk, with the subject of the talk as its theme. This worked very well, and we had some lively discussions going on after both talks, with the 50 or so attendents talking in four or five groups. I’m happy it worked out, as it was the first time I facilitated an Open Space.
My own talk dealt with Technical Excellence, and in particular with Test Driven Development, and why it’s a good idea to use it. My talk was heavily inspired by James Grenning’s closing keynote at the Scrum Gathering in London last year. He even allowed me to use some of his sheets, which were very important in getting the argument across. I’ll go through the main points of my talk below.
For me the big challenge was to manage to fit the most important parts of what I wanted to say within the 20 minutes I had available to me. As in software development, it turns out presentation writing is about making the result short, clear, and without duplication. The first attempt at this presentation took about 50 minutes to tell, and subsequent versions got shorter and shorter…
The complete set of slides is here. And this is how the story went:
I quickly introduced the subject by talking about Agile’s rise in popularity ever since the term was introduced ten years ago (and before, really, for the separate methods that already existed). About35% of companies reported using some form of Agile early last year, in a forrester report. Most of those companies are showing positive effects of this adoption. No matter what you think of the quality of investigation of the Standish Report, for their internally consistent measure of project success the improvements over the last ten years have been distinct.
That’s not the whole story, though. Many teams have been finding that their initial success hasn’t lasted. Completely apart from any other difficulties in getting Agile accepted in an organisation, and there are plenty of othere, this particular one is clearly recognisable.
There is a slowing of development. Usually due to having a lot of defects that come out in production, but also because of an increasing fragility of the codebase that means that any change you do can (and will…) have unforseen side-effects. One very frequent indicator that this is happening in your team is the increase in requests for ‘refactoring’ stories from the team. By this they usually mean ‘rework’ stories, where major changes (‘clean-up’) is needed for them to work more comfortably, and productively, with the code. In this situation the term ‘Technical Debt’ is also becoming a more familiar part of the vocabulary.
And that is why it is time to talk about technical excellence. And why the people who came up with this whole Agile thing were saying last year that encouraging technical excellence is the top priority! OK, they said ‘demand’, but I have less clout than those guys… They said other things, but this was a 20min. presentation, which is already too short for even this one. It is on top, though.
I further emphasised the need with a quote by Jeff Sutherland:
“14 percent, are doing extreme programming practices inside the SCRUM, and there is where we see the fastest teams: using the SCRUM management practice with the XP engineering practices inside.” - Jeff Sutherland, 2011
Since Jeff was nice enough to mention XP, Extreme Programming, this allows us to take a look at what those XP Engineering practices are.
We’re mainly talking about the inner circle in the picture, since those are the practices that are most directly related to the act of creating code. The second circle of Hell^H^H^H^H XP is more concerned with the coordination between developers, while the outer ring deals with coordination and cooperation with the environment.
From the inner circle, I think Test Driven Development is the most important one. The XP practices are designed to reinforce each other. One good way to do Pair Programming, for instance is by using the TDD development cycle to drive changing position: First one developer writes a test, then the other writes a piece of implementation, doeas some refactoring, and writes the next test, after which he passes the keyboard back to the first, who starts through the cycle again. And, since you are keeping each-other honest, it becomes easier to stick to the discipling of working Test Driven.
TDD is, according to my humble opinion, a little more central than the others, even if only because it is so tightly woven with Refactoring and Simple Design. So let’s talk further about TDD!
Test Driven Development has a few different aspects to it, which are sometimes separately confused with the whole of TDD. I see these aspects:
- Automated Tests
- Unit Tests
- Test-First
- The Red, Green, Refactor process
I’ve had plenty of situations where people were claiming to do TDD, but it turned out their tests were not written before the production code, and were at a much higher level than you’d want for unit tests. Well, let’s look at those different aspects of TDD, and discuss why each of them is a good idea.
Why Automated Tests?
This is where some of the wonderful slides of James Grenning come in. In fact, for a much better discussion of these graphs, you should read his blog post! If you’re still with me, here’s the short version: Every Sprint you add new functionality, and that new functionality will need to be tested, which takes some fraction of the time that’s needed to implement it. The nasty thing is that while you’re adding new functionality, there is a good chance of breaking some of the existing functionality.
This means that you need to test the new functionality, and *all* functionality built in previous sprints! Testing effort grows with the age of your codebase.
Either you skip parts of your testing (decreasing quality) or you slow down. It’s good to have choices. So what happens is that pretty soon you’re stuck in the ‘untested code gap’, and thus stuck in the eternal firefighting mode that it brings.
This seems to be a great time to remind reader that the primary goal of a sprint is to release complete, working, **tested **software. And if that doesn’t happen, then you will end-up having to do that testing, and fixing, at a later date.
To try to illustrate this point, I’ve drawn this in a slightly suggestive form of a… waterfall!
Why Unit Tests?
So what is the case for unit tests? Let me first assure you that I will be the last to tell you that you shouldn’t have other types of tests! Integration Tests, Performance Test, Acceptance Tests, … And certainly also do manual exploratory testing. You will never think over everything beforehand. But. Those tests should be added to the solid base of code covered by unit tests.
Combinatorial Complexity
Object Oriented code is built out of objects that can have a variety of inner states, and the interactions between those objects. The possible different states of such interacting components grows huge very quickly! That means that testing such a system from the outside requires very big tests, that would not have easy access to all of the details of all possible states of all objects. Unit Tests, however are written with intimate knowledge of each object and its possible states, and can thus ensure that all possible states of the object are covered.
Fine Grained tests make it easier to pin-point defects
Perhaps obvious, but if you have small tests covering a few lines of code each, when a defect is introduced, the test will accurately point to the defect with a couple of lines of accuracy. An integration or acceptance test will perhaps show the defect, but still leaves tens, hundreds or thousands of lines of code to comb through in search of the defect.
Code documentation that stays in sync
Unit tests document the interfaces of objects by demonstrating how the developer means them to be used. And because this is code, the documentation cannot get out of sync without breaking the build!
Supports changing the code
Unit tests are crucial to your ability to do changes to code. Be they refactoring changes or added functionality, if you don’t have detailed tests they chances of introducing a defect are huge. And if you don’t have those tests, chances are you’ll be finding out about those shiny new defect in production.
Why Test-First?
Ok, so we need unit tests. But why write them before writing the production code? One of the arguments is simply that there’s a good chance you won’t write them if you’ve already written your production code. But let’s pretend, just for a minute, that we’re all very disciplined, and do write those tests. And that we wrote our code in such a way that we can write unit tests for it with a normal level of effort. Time for another of mr Grenning’s sheets!
The full story, again, can be found on his blog, but the short version is as follows. It’s been an accepted fact in software development for quite a long time that the longer the period between introducing a defect and finding out about it, the more expensive it will be to fix it. This is easy to accept intuitively: the programmer won’t remember as well what he was thinking when the error was made; He might have written code in the same general area; Other people might have made changes in that part of the code. (How dare they!)
Now how does Test-First help alleviate this? Simple: If you write the test first, you will notice the defect immediately when you introduce it! Yes, granted, this does not mean that you can’t get any defects into production, there are many different types of bugs. But you’ll avoid a huge percentage of them! Some research on this indicates differences of 50 to 90 percent reduction of bugs. More links to various studies on TDD can be found on George Dinwiddie’s wiki.
Red, Green, Refactor
And now we get to the last aspect of TDD, as an actual process of writing/designing code. The steps are simple: write a small test (red), that fails; write the simplest code that makes the test pass (green), and then refactor that code to remove duplication and ensure clean, readable code. And repeat!
One thing that is important in this cycle, is that is is very short! It should normally last from 3 to 10 minutes, with most of the time actually spent in the refactoring step. The small size of the steps is a feature, keeping you from the temptation of writing too much production code which isn’t yet tested.
Clean code
Sticking to this process for writing code has some important benifits. Your code will be cleaner. Writing tests first means that you will automatically be writing testable code. Testable code has a lower complexity (see Keith Braithwaite’s great work in this area). Testable code will be more loosely coupled, because writing tests for tightly coupled code is bloody hard. Continuous refactoring will help keep the code tightly cohesive. Granted, this last one is still very much dependent on the quality of the developer, and his/her OO skills. But the process encourages it, and if your code is not moving towards cohesion, you’ll see duplication increasing (for instance in method parameters).
After last weeks presentation, in one of the Open Space discussions some doubt was expressed on whether a lower cyclomatic complexity is always an indication of better code. I didn’t have/take much time to go into that, and accidentally reverted to an invocation of authority figures, but it is a very interesting subject. If you look at the link to Keith Braithwaite’s slides, and his blog, you’ll notice that all the projects he’s discussing have classes with higher and lower complexity. The interesting part is that the distribution differs between code that’s under test and code that isn’t. He also links this to more subjective judgement of the codebases. This is a good indication that testing indeed helps reduce complexity. Complexity is by no means the only measure though, and yes, you can have good code that has a higher complexity. But a codebase that has a tendency to have more lower complexity and less higher complexity classes will almost always be more readable and easier to maintain.
Simple Design
XP tells you You Ain’t Gonna Need It. Don’t write code that is not (yet) absolutely necessary for the functionality that you’re building. Certainly don’t write extra functionality! Writing the tests first keeps you focused on this. Since you are writing the test with a clear objective in mind, it’s much less likely that you’ll go and add this object or that method because it ‘seems to belong there’.
Another phrase that’s popular is Don’t Repeat Yourself. The refactoring step in the TDD process has the primary purpose of removing duplication. Duplication usually means harder to maintain. These things keep your code as lean as is possible, supporting the Simple Design filosophy
Why Not?
So why isn’t everyone in the world working with this great TDD thing I’ve been telling you about? I hear many reasons. One of them is that they didn’t know about is, or were under the misconception that TDD is indeed just Test Automation, or Unit Testing. But in the Internet age, that excuse is a bit hard to swallow.
I’ve just spent quite a bit of time discussing hoe TDD will normally save you time, so it doesn’t make much sense to spend more time discussing why not having time isn’t an argument.
But there is one part of this objection that does hold: getting started with TDD will take time. As with everything else, there’s a learning curve. The first two or three sprints, you will be slower. Longer, if you have a lot of code that wasn’t written with testing in mind. You can speed things up a bit by getting people trained, and getting some coaches in to help get used to it. But it will still take time.
Then later, it will save you time. And embarrasment.
Sure. Not as many as now, but I’m sure there will be bugs. Still, that argument makes as much sense to me as saying that we will always have deaths in traffic due to people crossing the road, even if we have traffic lights! So we might as well get rid of all traffic lights?
There will always be some people that fall ill, even if we inoculate most everyone against a disease. So should we stop the inoculations?
Nah.
Uhm… Yeah…
At the same time the strongest and the weakest of arguments. Yes, in many companies there are bosses who will have questions about time spent writing tests.
The thing is: you, as a developer are the expert. You are the one who can tell your boss why not writing the test will be slower. Will slow you down in the future. Why code that isn’t kept clean and well factored will bog you down into the unmaintainability circle of hell until the company decides to throw it all away and start over. And over. And over.
You are also the one that that guy is going to be standing at the desk of, telling you that he’s going to have to ask you to come in on Saturday. And Sunday. And you know what? That’s going to be your own fault for not not working better.
And in the end, if you’re unable to impress them with those realities, use the Law of Two Feet, and change companies. Really. You’ll feel so much better.
This last one is, I must admit, the most convincing of the reasons why people are not TDDing. Legacy code really is hard to test.
There’s some good advice out there on how to get started. Michael Feathers book. Working Effectively With Legacy Code is the best place to start. Or the article of the same name, to whet your appetite. And the new Mikado Method definitely has promise, though I haven’t tried that on any real code yet.
And the longer you wait to get started, the harder it’s going to be…
How?
I closed the presentation with two sheets on how to get to the point where you can deliver at high quality.
For a developer, it’s important to keep learning. There a lot of great books out there. And new ones coming out all the time. But don’t just read. Practice. At Qualogy I’ve been organising Coding Dojos, where we get together and work on coding problems, as an exercise. A lot of learning, but also a lot of fun to do! Of course, we’ve also all had a training in this area, getting Ron Jeffries and Chet Hendrickson over to teach us Agile Development Skills.
Make sure that when you give an estimate, that you include plenty of time for testing. We developers simply have a tendency to overlook this. And when you’re still new to TDD, make a little more room for that. Commit to 30% fewer stories for your next three sprints, while your learning. And when someone tries to exert some pressure to squeeze in just that one more feature, that you know you can only manage by lowering quality? Don’t. Say NO. Explain why you say no, say it well, and give perspective on what you can say yes to. But say no.
For a manager, the most important thing you can do is ensure that you consistently emphasize quality over schedule. For a manager this is also one of the most difficult things to do. We’ve been talking about the discipline required for developers to stick to TDD. This is where the discipline for the manager comes in. It is very easy to let quality slip, and it will happen almost immediately as soon as you start emphasizing schedule. You want it as fast as possible, but only if it’s solid (and SOLID).
You can encourage teams to set their own standards. And the encourage them to stick to them. You’ll know you’ve succeeded when the next time you slip up and put on a little pressure, they’ll tell you “No, we can’t do that and stick to our agreed level of quality.”; Congrats:-)
You can send your people to the trainings that they need. Or get help in to coach them (want my number? :-)
You can reserve time for those practice sessions. You will benifit from them, no reason they have to be solely on private time.
Well, it’s nicely consistent. I went over my time when presenting this, and over my target word-count when writing it down. If you stuck with me till this end, thanks! I’m also learning, and short, clear posts are just as hard as short, clear code. Or short, clear presentations.