At the recent TDD Firestarter here in Tampa, a question came again that was a repeat of one from my TDD/MVC talk at Agile Tampa a couple of months back. Then, at the after-party of the Firestarter event, Joe Healy talked about needing a 10-step program for introducing TDD.
I gave some thought to this, and even outlined steps. But my mind kept going back to that question. The very strange question. The one that goes:
“How to I convince my management to let me get started in TDD?”
To answer, I want to take you back to earlier in 2008. I was sitting in a large hall being entertained by an uncle. Well, not my uncle, but Uncle Bob Martin. He was giving a talk called Quintessence: The fifth element for the Agile Manifesto. In it, he uttered the now infamous fifth addition to the Agile Manifesto:
Craftsmanship over Crap
Much was said about this statement, about how it didn’t fit in to the other items (since we never really value crap), and if there were better ways of phrasing it. Well, here ya go.
We have a problem in the software world. A problem that those 3 words uttered by Uncle Bob, filled with passion, almost a plea, drives home so clearly for me. You want responsibility? You want to change things? You want better tools, better processes, better software, more time at home, more money, etc, etc?
Then get off your butt and do it.
I’ve had the opportunity to see real craftsman at work – not in the software industry (although I have), but in ones like woodworking, metalurgy, and others. These people, these craftsman, have no ego. They know what they know, but aren’t afraid to learn new ways. They are equally not afraid of teaching, mentoring, showing examples of how to get better. They are teachers. They are mentors. They understand that to change things, to make things better, to get better, they have to work hard.
So, when they are building a beautiful Oak cabinet, or welding some critical piece of infrastructure, do you really think they go, “Wow, I learned this method that will greatly improve everything I do, will increase the quality, decrease my defects, and allow me to help people understand what it is I’m doing. If only my boss would let me do it.”
Bull Hocky. That’s a cop-out. A pathetic one at that. One that says that even though you know a better, faster, stronger way of doing things you are going to keep it to yourself. Worse, you are going to hide behind an excuse.
You want to know how to improve your software? You want to know how to become a better developer? Look to the craftsman. Get off your butt, get to some code, and start writing tests. Or pairing. Or translating business language to acceptance tests. Find a bug? Write a test that exposes it, and then is green when the bug isn’t present. Set up a local CI server. Make sure your stuff works. Know the SOLID principles. Know what the PoEAA book is. Look up things like Domain-Driven Design, Test-Driven Development, Behavior-Driven Development, Acceptance Testing, FitNesse, Ruby, Python, RSpec, Cucumber, NUnit, MbUnit, xUnit.NET, JUnit, JMock, JBehave, ScrewUnit, Spec#. Figure out why people always laugh about refactoring in Visual Studio and point to Eclipse. Figure out why the Visual Studio people laugh at the Eclipse people. Try J2ME. Try Windows Mobile. Try iPhone development. Learn Haskell. Learn F# (or just talk to Matt ;)). Learn Smalltalk. Read Death March. Read Slack. Read The Mythical Man Month. Read Clean Code. Find Computer Science books and read those too. Go to local meetings. Go to national conferences. Speak at Code Camps and user groups. Learn, and teach, and do, and learn, and teach, and do.
But don’t sit there and wonder how you’ll get your manager’s approval. If we want to change this industry, we aren’t going to do it with excuses. We’re going to do it by getting out there and being a part of it.
So, to summarize, how do you get your manager’s approval to do TDD? You don’t. And you do it anyway. Change your organization, or change your organization. But don’t just sit there. If you don’t run, you rust.