Discussion about this post

User's avatar
Simon's avatar

This reminds me of your comment at DDD Europe - paraphrasing from memory: it turned out that 70% of software cost was in the maintenance phase; why not make it 99%.

The original poster implies that the system is “done” after his first set of iterations. That’s really unlikely.

One advantage of TDD (/BDD/etc) is to assume that you’re never done and that behavioural composition goes on for the lifetime of the system: many years or decades.

And that value should be deliverable early: the skateboard not the car.

Start with tiny behaviour, compose, iterate (over those many years or decades).

Expand full comment
Malte-Levin Riewe's avatar

Hi Kent,

I started TDD deliberately just a year ago. And it provides me all the benefits you have described here and there. But I think what is often underestimated is TDD as a tool for learning and rapid skill improvement. I think my Software Design skill never increased so steep as in the last year.

This view came up when listening to a conversation between Dave Thomas and Dave Farley. Where Dave Thomas described that he dropped TDD for 6 or 12 months and there was now bug increase or design decrease. So I just started wondering what this means. I think it’s definitely a learning practice, while making meaningful progress on the problem you are paid for.

Pairing is not always feasible, AI not always accurate enough. TDD is a very high available high quality feedback loop that supports learning.

Expand full comment
22 more comments...

No posts