3 comments

[ 0.25 ms ] story [ 21.6 ms ] thread
It is good to see a respected teacher and theorist of the agile movement making the point that good judgement is preferred over dogmatic adherence to a set of principles.
Apparently this was posted a year ago, which is kind of frustrating for me because it's exactly the sort of analysis I've been hoping for since I was first introduced to TDD.

I'm not really comfortable with the space that he's constructing, but at the very least it's a space. Like if you had a bunch of requirements you might be able to actually determine if TDD makes sense via somewhat objective criteria instead of via whomever makes the best appeal to pathos.

What I actually want (and have been working on creating) is some sort of problem space[1] that allows you to analyze any given problem such that you can determine whether TDD will benefit or harm the development and verification of a solution.

[1] - It looks suspiciously like a general purpose problem space is kind of a ridiculous thing to try and define mathematically. I've had to set my sights a bit lower than my initial goal, but the ultimate dream would be objective analysis based off of high level discussion of what the stake holders want.

I feel like you get a feel for this as you grow gray. 98% of the code I write is not tdd.2% is instant tdd and I am happy for those times.

Things that make the tdd cut for me? Writing an algo. Maybe a maze solver. Maybe a payroll tax calculator. Maybe a monthly bill calculator.

I want these parts of my system rock solid, and it is super easy to make wack a mole where you fix one bug to regress a previously fixed bug. Love very solid TDD tests here.

Other 98% if my app? No way. Tdd adds cruft and can steer you to local maxima aND away from the optimal solution.