My approach: agile pragmatism, and the agile as the application of scientific method to software development

Agile pragmatism

Ideologies are bad, m’kay? Instead aim for strong opinions, weakly held

Blindly adhering to any methodology without adapting is not a good thing. There are no truths handed down from on-high, just the best thing we know right now.

Agile is the scientific method

I tend to view agile done well as the application of the scientific method to software development. Not just the writing of the code, but the whole process around it.

The Scientific Method 1

For any piece of code you’re about to write:

The feedback loop is the key similarity, and the thing that distinguishes either from a ‘classic waterfall’ approach. In practice, in both applied science (say Medical Research), and coding, people seem to forget the ‘think’ step. And when formulating tests, sometimes they seek to prove their hypothesis, rather than seek to prove it wrong. I guess that’s human nature.

It’s remarkable; when I’m pairing with a dev — maybe they’re new to TDD, maybe they’ve been going through the motions for years — how much of a revelation they find my suggestion of testing the negatives, of proving yourself wrong. It’s a mindset shift, but it’s a powerful one.

Does this slow you down? It depends on your timescale, your familiarity with the approach, and the complexity of the test necessary to prove your hypothesis. On a short timescale of between writing the functioning code, and seeing the results from a run - it doesn’t necessarily payoff - as is the case with much TDD. As you get better at formulating meaningful tests, exploring the boundaries and the negatives, and the failure modes, you’ll find your pace accelerates due to the harness(es) you have built.

Once you adopt the approach, and practice, it becomes seconds nature. You’ll begin to feel uncomfortable without a solid testing approach (I almost said Framework, but you can adopt the approach without the framework). You don’t need a framework, because for somethings you do you may not need the regression tests that would grow out of it. You were just doing exploratory testing to establish what should be added to the regression set.

The key is continual feedback. And perpetual refinement. Also, don’t be afraid to reject long held hypothesis if something is proven to fit the problem better (I should write something on committing the Sunk Cost Fallacy - and institutional inertia).

Change just one thing

The other thing I always try to limit myself to: Change just one thing!

In any given development cycle, change just one thing. This can be a difficult habit to get into. We want to feel productive. Plenty of developers are mighty smart, they are confident in their abilities. They’ll try and tackle a ‘couple of things’. I don’t mean features - though I’ve seen that too. I mean in unit testing, did you just add something that forces you to introduce an if? Then only add the code for one branch: No matter how simple it seems to do the other branch. Focus only on the behaviour you’re driving with tests.

Summary / Conclusion / tl;dr;

  1. I Nabbed the scientific method picture here, via wikipedia

Lance Paine 03 March 2016
blog comments powered by Disqus