Having personally developed lots of software as well as worked with many software developers over the years, I’ve formulated a theory on why lots of developers are resistant to unit testing and test driven development (TDD). The theory is simply that most developers know that 90% (or more) of the lines of code they write are defect free; consequently, forcing 100% of the code to have tests seems counterproductive to many of them. It’s a theory that seems obvious after being said out loud, but I rarely hear it explicitly verbalized in discussions to increase testing.

The mental hurdle that is difficult to overcome is that the 5-10% of the code with defects is like a minefield scattered throughout the product. Many Agile software processes promote a test first then code approach, and this considered a mythical utopia by most software shops. Even though more companies are adopting test first strategies, the key to changing the mindset has to occur in technical textbooks and classrooms. After the ‘hello’ program has been taught, all other examples should start with a test and proceed from there.

At last year’s Agile conference, I was entertained to hear one of the group discussions involve ‘relating Agile software development to every day situations in life’. I didn’t attend this group discussion, but there have been many times over the past year where I have taken a mental note of some similarities. While this will surprise very few people, since our work processes often stem from actions outside of work and vice versa, some of the similarities help explain why Agile works in developing ‘craft-like’ products, such as software. I’ve listed a couple of incredibly simple ones, but there are many more.

Paying bills. As any financial planner will advise, a wise person should pay their utilities and other necessities before buying that new ceramic unicorn for the collection. With an Agile process, the truly important features are added first, and once these features have been added, the extras are worked into the product. In the end, there’s little chance of the electricity being turned off!

The big spelling test. When I was in 5th grade, I aced a ~70 word vocabulary test that we were given a couple of weeks to prepare. I’m no word buff, but when the teacher asked me to explain to the class how I did it, I said I had casually studied 5 new words every day for the past couple of weeks. I hadn’t tried to learn the whole list all at once nor cram a few days before the test. This is very similar to the iterative approach prescribed by Scrum and other Agile methods. Break the work out into discrete blocks and concentrate on those blocks for short periods of time.

The point is not to trivialize Agile processes in general, but it is important to note the methods used in Agile are also methods that generate higher success rates in other practical areas.