What went wrong at ${Job Sept’09-Oct’09}

[elfs]

Gwaredd Mountain writes:

Microsoft has published empirical data that shows that the process overhead for TDD increases the development effort by 15% – 35%. Despite the many positive benefits from TDD, we cannot possible consider anything that adds an extra 35% effort to produce artefacts the customer will never see as lean. Amazingly, people still try and associate this with “agile”.

That was, more or less, exactly what went wrong with the social networking group with which I was involved. We were sold both Agile and TDD at the same time, and the contradiction between the people oriented development cycle of Agile (something at which I excelled at CompuServe), and the process-driven development cycle of formal TDD, is what doomed the project and made it limp along without a real direction. Nobody ever stopped to ask what the whole thing was supposed to do; their were just these modules, all encrusted with a half-dozen tests, each ensuring that the module it tested conformed to some specification that existed only in the tester’s mind.  My mind included.

I believe that some process is important, even inevitable.  But I could see the inherent friction in the TDD and Agile development processes that paralyzed a company’s forward development progress.   I think the 37 Signals approach of “It’s a problem when it’s a problem” is one of the best pieces of advice I’ve ever seen, or as I put it, “I write code until I do something stupid, then I write a test to make sure I don’t do that stupid thing again.”

This entry was automatically cross-posted from Elf's technical journal, ElfSternberg.com

Comments

[bolindbergh]

How is it's a problem when it's a problem different from use two-digit years until 1999?

[(Anonymous)]

I dunno if that's fair. There were any number of operations with ostensibly higher testing standards who fell into the Y2K trap. The problem was that people just didn't envision their software lasting that long, and that same assumption crept into their unit tests. In other words, it was a failure of foresight more than a software quality problem.

Number 127

[elfs.livejournal.com]

It's not. But I'll point out, the world's still here.

[http://users.livejournal.com/_candide_/]

TDD, done fanatically, is as bad as any other programming method done fanatically. You paint yourself into a corner.

I find that writing tests as you're writing the code works best. Even then, one should only write tests for non-trivial code and/or code with non-obvious behavior and/or critical pieces of code.