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 and heard someone mention we needed a fifth element for 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.
There isn’t.
We have a problem in the software world. A problem that those 3 words captured 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. 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.
Great post, Cory. I know a lot of devs who think they need management approval to get to work in a room together to they can do Agile or use work items. My team is spread out across the country and we have a daily Scrum over the phone and Live Meeting. Shared View makes it easy for folks to pair up. Those are just a couple of examples. I think it would be great to hear from other readers examples of dev teams improving their practices by their own initiative.
jb
I agree that you don’t need permission. You can just do it.
But… This advice is a cop-out as well.
People aren’t just asking this question because they don’t want to do it. They are also asking it because they are actively being punished by their peers for practicing TDD.
It is them who convince management that TDD is a wasteful and therefor bad thing to do. Or at least they’ll come up with some way of saying that you should apply TDD as needed. A convenient way of saying you can sometimes do it but in practice you must never.
When I work with someone open-minded there is never a problem. But ask me to practice TDD with someone who strongly believes TDD isn’t useful…
I am often at a loss on how to teach such people.