There has been a fair amount of activity in the blogsphere to Roy's original post about increasing TDD adoption. Roy updates some of the reaction here and here. Udi comments on my reaction that the most important thing is to being writing tests and then learn how to write them better. Udi questions whether it is right for us to expect customers to allow us to learn on their time. And Casey Charlton makes a similar point in comments on Tim's blog. There has been a fair amount of discussion as to how we teach TDD over at the TDD mailing list too.
I have not changed my position in response to these comments, but I did want to talk a little about change and learning.
Embrace Change
The XP strapline was 'Embrace Change' and it remains, to me, at the core of key alt.net ideals like Continuous Improvement. Our field is contantly changing. New technologies, practices, and methodologies emerge with alarming frequency. Sometimes the pace of new developments can seem frightening. We can have two reactions to such change: resist it or embrace it. The danger with resisting is that we stagnate, stuck in the comfort zone of what we know. I see a lot of resistance to ideas like TDD simply because people do not feel comfortable with changing practices. Alt.Net is for me about the idea of embracing change, of continuous improvement. Embracing change for its own sake has its own dangers of course. The urge to try the latest thing can lead us into peril if we fail to critically evaluate its value to us.
My experience is that change usually occurs when the pain of existing practice becomes so great that it pushes aside the resistance to change. There must be a better way, we think. My experience of test-first development is that the pain of the test and debug phase at the end of waterfall projects pushes people to look for solutions. Solving issues here improves delivery, reduces cost, and increases customer satisfaction. As the cost of that phase rises and projects slip due to the uknowable length of making the project fit for release, the customer begins to feel the pain of older approaches. The promise of test-first approaches, building quality into the manafacturing process instead of in a seperate QA step, becomes attractive enough that people trial the new ideas. There is business value in agile processes, which can be demonstrated by solving the typical pain problems that organizations not using agile development practices have.
My point on the most important step being to start testing, over worrying about following best testing practice is that the value of building quality in can be quickly seen. Once a team realizes that value in test first approaches they will buy in to learning how to do them better. But its that first buy in that counts. People worry about whether test-first is about testing or design. It's simply about quality - which includes both of those and more.
Of course there is a leap of faith on the first project. My experience is of pilot projects which trial these new approaches and compare results against existing processes to persuade key decision makers of their value. Often we try new techniques or technologies on lower-profile or even internal to IT projects to assess their value over high risk high profile work. This is not always the case. Once we buy into newer technologies or practices we may choose to up our game and improve our use of them on high profile projects because people have the motivation on them to try something new.
While I agree with the idea that developers have an obligation to
their own professional development, there is always a difference between learning a new skill and improving our ability with that skill through practice. I can read volumes on TDD best practices, but it is only for trying it out in anger, at some scale, that I can master it. For many, it is only practice that provides the encouragement to learn more. This kind of practice always has to be on the job, in this and in every other field. You can do all the book learning and training you want - ultimately you have to practice to master a skill. We train our developers when we want them to work with new third-party products that provide us with document management, rules, feeds etc. Why would we not want to train them in better practices? I have and continue to give training at my current organization and would expect to continue to do so. I have received training from my current organization. This is occurs in all professions.
At a discussion in our recent London altnetconf Alan Dean
pointed to the observation that agile practices often depend on agents
of change, and they can ebb and flow within those organizations with
the arrival and departure of such agents. The key to change is often individuals who learn and practice new techniques, or who bring experience of those techniques from other organizations. I love working with new people who have strong agile backgrounds because they bring with them fresh ideas and new perspectives to challenge me.
But to gain from thier experience we have to accept that we will need people to accept change and work in new ways. And they may not get it right at first. There will be a learning curve.That for me is why reflection workshops/sprint reviews are so important. They create the discipline of examining our use of practices and techniques and encourage us to get better at them. So the team that picks up TDD and just does it has plenty of opportunity to see the pain of talking to the Db or touching the file system, look for solutions and correct their course. Will there be additional cost to learn. Of course! But the cost of not learning is far higher.
Posted
Fri, Oct 10 2008 9:18 AM
by
Ian Cooper