This is my first real blog entry, and so it seems like a good opportunity to unload some thoughts I've had about Agile, Agile Practices, the agile community and TDD in general.

I don't know that I deserve much credibility, but I am a professional software developer with over a decade of experience. Roughly two years ago, I was exposed to TDD and agile concepts by Chad Myers and Ray Houston when they were hired as consultants with a former employer. Prior to that, my experience had been all waterfall, beginning with the company that wrote the book on waterfall, EDS.

Shortly after learning some basic agile concepts from Chad and Ray, I left that employer for the promise of professional growth in a more open environment. After that didn't work out, I found myself at a company where I am allowed to try and improve my skillset and practice what I have learned. However, this is in the context of diving back into old methodologies and practices as the current projects demand. At present, I have yet to see a project through to completion using agile methodologies. I have written several hundred unit tests, but often these were done post-development, so I could also say that I have not done any true Test Driven Development in a project from start to finish.

It is interesting that when a changing influence comes into your life, the first thing that has to change is you. This is true no matter what the changing influence is: whether Christ, family, diet, or agile. If you are not open to receive the new ideas and embrace them within yourself, then that change cannot happen. Also, the change isn't something that's going to just happen to you: you have to work at it to supplant the old with the new. Having embraced the new idea, you have to work to rid yourself of existing habits and practices that are contrary to the new ideology, and practice those tasks brought by the new ideology until they become habit. This takes a high degree trust that the new ideology will deliver what it promises, because invariably, change involves risk.

Once you have begun to change yourself, it is natural to want to influence others to believe as you do. Working with others who share your beliefs makes accomplishing tasks much easier. Additionally, you do not feel isolated or alone, and as you experience more success, others witness that success and are drawn to the ideas, empowering even more and greater success. However, anyone that you share your beliefs with has to overcome the same challenges that you did when you first received the new ideas. There are several factors that influence how readily someone can accept new ideas:

1. The strength of the idea


2. The degree of trust in the messenger who is communicating the new idea; and


3. The degree of success and comfort the individual has with his previous ideas (a negative factor).

In order to gain acceptance, any new idea or philosophy must have some inherent appeal. For agile, this appeal is the hope of future success and the promise of remediation to existing failures and frustrations. For a software developer or team that has been mired for years in the frustrations typically associated with development (unrealistic deadlines, long hours, tense relations with management, difficult code maintenance cycles, etc. etc.), this is a tremendously strong appeal. But is it enough?

Why should anyone who has been developing for years immediately trust that this new idea can work? Sure, all the big software companies do it, or so they say. But if you've been caught in the mind-numbing cycle of meeting deadlines and then fixing the bugs generated trying to meet those deadlines, you're probably not able to do a lot of research on your own. How can you verify that the new ideas are valid? This is where trust in the messenger comes in to play. You can learn to trust someone for several reasons: previous associations, good reputation, well-reasoned arguments. All of these serve to build that trust, but ultimately it comes to an act of faith - saying that the strength of this person's argument alone is worth a risk.

So, ideas 1 and 2 have been established - there's a strong new concept and it has been proposed by someone you trust. Step 3, giving up what you "know", is often the hardest. Even when "what you know" is unreasonable and demonstrably unproductive. We see this played out in life all the time: the battered wife who continues to return to the home of the batterer; the alcoholic that continues to ignore help; ignoring calls of creditors rather than changing your spending habit. People want to stay with the familiar because it is more comfortable than the risk of change. From experiencing various needs to change personally, I've learned that overcoming yourself is the most difficult and challenging task of all.

You can start a project using TDD, but when it gets close to the deadline, you're instructed to leave off the testing for now because it takes too much time to write the tests. Or developers around you don't see the immediate benefit of testing because it's too hard (you do, after all, have to re-learn the way you write code). Or, you sabotage yourself: you're in the middle of a project, the deadline is coming up but you get pulled into too many other tasks and aren't meeting milestones. So you resort to what you know, and the tests get forgotten.

If you're going to become successful, you need to go back to the tests at every opportunity. Try to keep them going, evangelize to those around you. Ultimately, with patience and time, you will build momentum and start to see real change. Other developers will start to trust the quality of your work. Management will see the shorter testing cycles. Demonstrating solutions to problems becomes much simpler, and light-bulbs start to go off around you. Factors 1 & 2 start to become evident through you, even as you work out factor 3 within yourself.

This is a process, and there may be many short-circuited projects during this time. But when you've seen the goal, all you can do is to keep pressing. To borrow from Paul in the book of Phillipians, Chapter 4:

12 Not that I have already reached [the goal] or am already fully mature, but I
make every effort to take hold of it because I also have been taken hold of
by Christ Jesus. 13 Brothers, I do not consider myself to have taken hold of it.
But one thing I do: forgetting what is behind and reaching forward to what
is ahead, 14 I pursue as my goal the prize promised by God's heavenly call
in Christ Jesus.

You just have to let patience be its own reward - for a time.