December 8, 2018

...Learn TDD with Codemanship

True Agile Requirements: Get It Wrong Quickly, Then Iterate

I'm going to be arguing in this post that our emphasis in the software design process tends to be wrong. To explain this, I'm going to show you some code. Bear with me.



This is a simple algorithm for calculating square roots. It's iterative. It starts with a very rough guess for the square root - half the input - and then refines that guess over multiple feedback cycles, getting it progressively less wrong with each pass, until it converges on a solution.

I use this algorithm when I demonstrate mutation testing, deliberately introducing errors to check if our test suite catches them. When I introduce an error into the line that makes the initial guess:



e.g., changing it to:



The tests still pass. In fact, I can change the initial guess wildly:



And the tests still pass. They take a little longer to run is all. This is because, even with an initial guess 2 million times bigger, it just requires an extra few iterations to converge on the right answer.

What I take from this is that, in an iterative problem solving process, the feedback loops can matter far more than the initial input. It's the iterations that solve the problem.

When I see teams, including the majority of agile teams, focusing on the initial inputs and not on the feedback cycles, I can't help feeling they're focusing on the wrong thing. I believe we could actually start out with a set of requirements that are way off the mark, but with rapid iterating of the design, arrive at workable solution anyway. It would maybe take an extra couple of iterations.

For me, the more effective requirements discpline is testable goals + rapid iterations. You could start with a design for a word processor, but if your goal is to save on heating bills, and you rapidly iterate the design based on customer feedback from real world testing (i.e., "Nice spellchecker, but our gas bill isn't going down!"), you'll end up with a workable smart meter.

This is why I so firmly believe that the key to giving customers what they need is to focus on the factors that affect the speed of iterating and how long we can sustain the pace of evolution. The cost of changing software is a big factor in that. To me, iterating is the key requirements discipline, and therefore the cost of changing software is a requirements issue.

Time spent trying to get the spec right, for me, is time wasted. I'd rather get it wrong quickly and start iterating.








Posted 19 hours, 34 minutes ago on December 8, 2018