There was no requirement for Twitter!
Return on investment from software is far from certain.
Two recent blog posts seem to indicate that there are software development environments where core agile development practices like
TDD and especially
BDD do not fit. Those "high-ceremony" practices are even considered as
waste:
Test-Driven Development and Embracing Failure
by Steve Freeman
Steve draws the difference between
ordered and
unordered domains and between
fail-save and
save-fail approaches.
TDD/BDD are fail-save approaches. We are assuming an ordered domain: we know the relation between cause and effect and we can write specifications/expectations and we can verify them pretty reliably.
Here we have a "specify-verify" feedback-loop:
In unordered domains we don't know the relation between cause and effect. Here it is pretty difficult to write specifications/expectations and to verify them a priori. It's mostly only possibly to gain insights after having been exposed to the "real world".
Here we have a "try-error" feedback loop:
The most important thing is that the effects of failure will not have too bad and that you can react very quickly and make improvements based on the insights of those failures (and successes).
Agile is about embracing change. Some domains are best tackled by embracing failure.
The Dark Side Beckons?
by Obie Fernandez
Obie argues that classic web startups have to find their place in the market. The real test here is feedback that is gained from success (or failures) of the deployed app.
It's much more important to be testing against business metrics (user-count, ratings, click-throughs ...) than anything having to do with code. Those insights can only be gained from the market itself.
So the feedback-loop here goes not "spec-implement-verify" but it must include deployment and market response: "spec-implement-deploy-inspect".
Having an
instant deployment pipeline is crucial to be able to react in this feedback loop.
My personal feeling is still that TDD (and even BDD) might make sense in the implementation phase of projects that tackle unordered domains.
I see that TDD/BDD in the sense of "discovering" behavior, in the sense of requirements gathering makes not much senese here. But they still help to ensure the correctness of the implementation, without a "correct" implementation, inspection makes no sense ...
But the "high-ceremony" aspect must be kept low and very pragmatic.
... however I might be clinging to my perception of the world... there are also people that claim that you can do agile development inside the phases of a waterfall...
