The smallest good deed is better than the greatest good intention

Everyone has heard this platitude - which of course, doesn’t make it false.  Here’s another way to think about it: Limit your W.I.P. - it’s better to get one little thing done than to have a mountain of unfinished “good intentions” and as soon as you get one thing done, finish the next.

Now, I’m not saying do one thing at a time, but I am saying limit your work in progress such that you are completing tasks in a timely manner. As you complete tasks begin new tasks that are pending. Get into a cadence where you’re delivering value frequently. Actually getting work done makes much more business sense than trying to make yourself (or your department) look like a dragon slayer by taking on too much simultaneous work. If you’re doing everything, you’re likely getting nothing done.

Reduced maintenance costs pay for the overhead of TDD

Interesting study on TDD done by Microsoft (link at bottom). The study seems pretty thorough - focusing on four different projects and using control groups working in the same problem domain on similarly complex tasks.

The study shows a 15 - 35% increase in overhead at the time of coding. That could be costly. It should be pointed out that only one team saw that an increase of over 25%. The other's maintained below that. The study points out that pre-release defects were reduced between 40 and 90% (FTW) - -All the teams demonstrated a significant drop in defect density: 40% for the IBM team; 60–90% for the Microsoft teams..

"From an efficacy perspective this increase in development time is offset by the by the reduced maintenance costs due to the improvement in quality (Erdogmus and Williams 2003), an observation that was backed up the product teams at Microsoft and IBM." - from the study

Pretty good defect decrease, not to mention the added maintainability garnered from the decoupling required to add good test coverage, better focus on design (as is the real goal of TDD), and the bonus of having thorough test coverage for fast regression testing.

Less technical debt at release, easier maintenance due to decoupling, assurance through existing tests that maintenance updates and bug fixes haven't affected existing functionality (introduced new bugs) adds up to a lot more budget available for creating new business capabilities instead of spending on keeping the ship floating.

"Our experiences and distilled lessons learned, all point to the fact that TDD seems to be applicable in various domains and can significantly reduce the defect density of developed
software without significant productivity reduction of the development team." - from the study

Read about it: http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf