The Freak Parade

So this crazy metaphysical debate about how or why you (or your team) should learn TDD rages on, reaching a fevered philosophical pitch. There is a heavy drumbeat coming out of the ALT.NET encampment that is becoming increasingly difficult to ignore, and we’re finding ourselves torn on how to react. Do we have a moral imperative to march along? Is it enough to tap our feet under our desks and keep doing business as usual? Or should we tear off our clothes, paint our faces with the ALT.NET war paint, and take our place by the campfire? Ian Cooper recently pointed out that what is at question here is not TDD but the imperative for us, as an industry, to accept change as a fundamental aspect of our practice.

Change is nothing new. In fact, change is all there is. We all attempt to resist it in one way or another, but it is a useless effort, like trying to stand still in a rushing river. There is no such thing as "resisting" change – the best you can do is to pretend it doesn’t exist, but you can’t stand still. Even though you may not alter your behavior, your environment will change around you and your relationship to your environment will change despite your stubbornness, it can’t be helped. Whether change is good or bad is a meaningless question, and the question of whether to accept it or ignore it isn’t really a question of "self improvement" but a question of how much you will enjoy your profession and your life.

So while the call to change coming from ALT.NET is extraordinarily valuable, the relentless emphasis on the tangible business results of some particular change, such as a guaranteed suite of regression rests resulting from a move to TDD, creates a limiting environment in which to accept it meaningfully and realize its full value. The only way to accept change is to experience it with an open mind and feel its value for yourself. An emphasis on quantitative results is absolutely necessary for arousing interest in some new technique or methodology, but it should not be the only emphasis. Once interest is aroused the emphasis should immediately shift from the expected benefits which, at this stage only reinforces preconceptions and inhibits the learning process, to remaining observant, alert and curious about the actual experience and actual results the technique or methodology provide.

TDD is a perfect example because everybody is always talking about its objective benefits, such as a safety net for major refactorings, enabling collective code ownership, cleaner API’s resulting from testable API’s, but the real value of TDD is a complex mix of all of these things and more. You can listen with your jaw agape to  someone extolling its benefits for days at a time but until you actually start to practice it you can’t really have any understanding of it at all. This is true with everything, but with TDD the effect is very dramatic, and therefore very instructive. People are always saying "it’s about design, not testing" but then they go on to describe benefits that are often mostly about testing. This is because the design aspect of TDD is something you will feel when you try it with an open mind, it is extremely difficult to articulate. The results are not so hard to articulate, such as decreased coupling or increased isolation, but an understanding of why these benefits result from TDD is more visceral than intellectual.

People talk about learning curves as if they were impediments to obtaining the bountiful rewards of some shiny new methodology, but the learning curve is exactly what produces the rewards. The learning curve IS the primary value. The moment the learning curve flattens out is the moment you will find a new methodology to replace the old one. Ian said in his post that change results from the pain of a process outweighing our natural resistance to change, but I completely disagree. I believe change is the fundamental and most basic aspect of our professional lives, the very reason we enjoy what we do as much as we do, and that methodologies evolve not at the last possible moment when we can’t stand the agony any longer but at the first possible moment, the very moment we suspect our current practices cannot evolve any further. A work environment where nothing changes, where technologies are frozen at some arbitrary point in time and previously established development practices have taken on the aura of biblical law are most developers worst nightmare.

Yet, as Udi Dahan points out, we often feel we are not at liberty to go off experimenting with change at the expense of pressing business realities. And this is true to a large extent, and I agree with his conclusions – TDD or any other new process should be introduced into an environment responsibly, ensuring an appropriate level of safety for the business as well as the team, or the results could well end in disaster. The danger, though, is to use that as an excuse to avoid accepting change altogether. While it is suicide to ram some new methodology into the gears of a running machine, a more sinister form of suicide is to neglect change entirely because no time ever feels like the right time. Consciously and constantly adapting to change should be built into the foundation of your business culture and your development culture. This is the responsibility of the management and line level developers alike. If your company is not interested in continuously evolving along with the software industry and therefore does not provide a safe (if controlled) environment for experimenting with and adopting new technologies, practices and methodologies then you should find another job. Conversely if a developer on your team is not interested in adapting to change then you should transition them off your team, either out of the company or into a support role.

Finally, all this highlights for me the need to emphasize that business results are not why we come to work every day. You may like to believe that you invest yourself as deeply as you do in your career because you want to contribute to the success of your business, or provide the best possible experience for your users, or streamline business processes, and these things mean something, but you know and I know that those reasons aren’t the real reason you show up at your keyboard. You love your job because it is mysterious and fascinating and full of creative possibilities and interesting logical puzzles which give you immense pleasure to solve and explore. You love to create something out of nothing. Fortunately, this kind of enjoyment usually aligns, or can be made to align, quite well with business objectives. But the point is motivation – yes developers want to be efficient, yes developers want to deliver maximum business value, but even more than that they want to maximize their creative possibilities and they want to enjoy the time they spend in front of their computers. So if you want to sell TDD, Agile, IoC, or whatever it is, don’t forget to sell that aspect of things as well as the objective, tangible efficiency or quality gains.

My team recently attended an Open Space conference, Open Agile 2008, which is a sort of new age, ad-hoc, self organizing meeting of passionate people. An Open Space conference has a number of principals, but the one that really caught my attention was the commandment to "Be Prepared To Be Surprised." What is meant is this: put aside your pre-conceptions and expectations and expect to learn something new at any given moment, and in unexpected ways. This applies equally well to a new technology or methodology such as TDD: "You will come away with full test suites that will dramatically improve the quality of your software, your designs will have lower coupling and a cleaner API and fewer defects. Oh, and be prepared to be surprised."