Test-driven development (TDD) has been seen as an aspect of the Extreme Programming (XP) methodology since the rapid growth of XP mind-share in the early 2000s. This view has begun to change as more developers are trying TDD even without a commitment to XP. Here I’ll talk about just a few of the important things you should and should not do when developing with TDD.
Much has been written about process improvement in the software industry. The SEI has developed the CMM (now known as CMMI) for about twenty years, yet according to a survey of 2000 government and commercial organizations about 50% are still CMM Level 2 or lower [1]. This is not surprising considering estimates of project failures typically run very high (some estimate over half). The higher levels of CMM are designed to insure repeatability of successes as well as identification of and improvement on failures, so we might assume that organizations operating at a higher CMM level have fewer failures. This leads to an interesting question. Why would a company not improve their process by means of application of CMM KPA’s or other forms of process improvement?
I was thinking about my claim that all development will move to the Mac when I realized that there is an obvious exception. The Artful Dodger. Why? In order to avoid responsibility, and reduce efficiency.