What’s The Diff?
One of the problems I’ve always had with the word “agile” is that it’s so overloaded (like “system“) that anyone can claim “agility“:
Everyone is doing agile these days – even those who aren’t – Scott Ambler
Along this vein, check out this slide from a unnamed agile expert:
Now tell me, how is this advice different from the unconscionable and anti-agile:
To define tests, you have to have some understanding of the requirements to test against in your cranium, no? It’s just that, in agile-land, you’ll be excommunicated from the cult if you formally write them down before slinging code. WTF?
Like “agile” was a backlash against “waterfall” in the past, maybe “waterfall” will be a circular backlash against “agile” in the future?
Likewise, instead of creating an emergent Frankensteinian design with revered “TDD“, why not hop off the bandwagon and create emergent tests with “DDT“?
Leave a Reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
Great post. I’ve been taught that when loops seem to be circular, it’s time to try to think out of the box and synthesize the larger system that drives the circularities in the first place.
You’re right that the word “agile” is overloaded and has lost the meaning it’s original proponents had.
You’re right to draw the parallel between testing and requirements in those two slides
You’re right to criticize extremists who suggest that you never write down requirements before starting to code.
But I don’t think I’ve ever met any of those extremists, in person (although I’ve met plenty of eXtreme Agilists 🙂 ) – and I consider that position a bit of a strawman in general.
The way I use TDD – and that way all practitioners that I know use it – is as a way of capturing those requirements in code such that I can verify that the production code meets them. This does not preclude those same requirements being written down prior to that in some non-code form – and in fact that is the whole focus of BDD – and most Agile approaches in general. BDD extends the language of TDD to a ubiquitous language for non-developers to communicate those requirements in a way that can be more seamlessly translated to the code level – providing a nice kick-off point for writing those tests. It’s also a recognition of the fact that the word “test” in TDD can be a bit misleading – BDD couches them more as executable (if that) examples of specification.
The whole “don’t write requirements before you code” myth is based on a misunderstanding of what was wrong with waterfall. What Agile rejected was the attempt to capture *all* requirements – along with estimates – often down to quite a fine level of granularity – before *any* code is written – with testing held off until after the coding is complete (although, in practice, even waterfall was rarely quite so segregated).
So you’re right to call out those that have misunderstood this and try to push their misunderstandings on others. But be careful not to fall into the same trap on the other side.
Thanks for the thoughtful commentary. I think the big difference is that methods, practices techniques that work well in the mobile and web world don’t work well in the safety-critical systems world – and vice versa. The systems I work on demand more upfront thinking and less emergent serendipity. There’s too much at stake.