There was no requirement for Twitter!
- Kevlin Henney, Putting the "re" into Architecture
Return on investment from software is far from certain.
- Jeff Patton, Using Design Thinking to Stop Building Worthless Software
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...
The twitter story is the one in a million story. Now, the question is whether best practices/experience will increase the probability of a one in a million story. The answer is likely to be no, because these story contain new stuff, that typically does not benefit much from experience. And really new ideas rather don't come to fixed and so called experienced minds. (side note to Kant could be considered here ;-) )
ReplyDeleteHowever, this doesn't reduce much the value of best practices (as I would consider TDD/BDD as well as agile etc) since most of the products/projects are not the one in a million project that will change the world. And improving those 99.9999% is probably as important.