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.
For any piece of code you’re about to write:
- Think (form, alter, refine or reject hypothesis)
- Now think how to measure it
- ‘Write’ your test (create your experimental protocol)
- Execute test - see it fail
- Write the code
- Execute tests - see them pass
- Refactor
- Goto beginning
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;
- Agile development done well IS the scientific method applied
- Testing pays off sooner than you expect
- Don’t just test the positive cases, come up with the negatives