Friday 5 PM Release Anxiety
June 23, 2023
How would your Scrum team feel if asked to release on a Friday at 5 PM? Nervous? Mitch Lacey posed this question yesterday, and it
I hear from teams and their managers that Test Driven Development (TDD) is taking them longer than their usual development practice. That’s not been my experience at all. But I can see where some may get the impression that TDD is slower.
Let’s say we’re writing some code for a new feature. And it takes X amount of time to write that code. When doing TDD we also incur the time cost of writing Y amount of unit test code. And quite often there is more unit test code than code for the new feature. When we compare that amount of time – unit tests and feature code – against just writing the feature code, then of course it appears slower.
However, in the Test Last case we’re not accounting for the time it takes to verify the feature is working. On one system I worked on here is what it took to verify the feature code I had written:
Because of the overhead and steps involved in Test Last I found myself batching up changes so I could test many things at once. Which led to me being not as rigorous with the testing, and often messing things up because of the manual nature of so much of that process.
With Test Driven Development I can confirm my feature code on my own machine without involving all of those steps and delays. When my unit tests don’t behave as expected it’s in the context of code I am currently thinking about and not something I may have written hours or days before. I get into a very fast feedback cycle of how I expect the code to behave, via unit tests, and writing code that behaves that way.
And a nice side benefit is that over time I also end up with a suite of regression tests that can instantly alert me when new code breaks an older part of the system.
It’s obvious to me why I do TDD, so why haven’t all teams adopted it? Well, to start, not many developers have been taught to approach writing software this way. Our traditional education teaches us how to code first, then test after. Test Driven Development asks us to drive development by flipping this approach around, to write a test first, a test that fails, then write the code that gets that test to pass.
This TDD approach is like any new skill. It will take time to adopt and have it become a natural part of your development. Think back to when you learned to ride a bike or drive a car. How awkward it felt, the mistakes you made, until it started to click. And now you can drive or ride without a second thought and those vehicles propel you faster and farther than you can go on foot. Test Driven Development is that vehicle that makes me faster.
Paul Moore is a Technical Agile Coach with Rocket Nine Solutions.
How would your Scrum team feel if asked to release on a Friday at 5 PM? Nervous? Mitch Lacey posed this question yesterday, and it
Over the years, we’ve worked with numerous banks, fintech, insurance and other financial services providers. Two things are clear: The finance and banking world is
We are walking through the three sections of Agile Leadership Training offerings from the Scrum Alliance, explaining their particulars in three separate posts to empower
Copyright © Rocket Nine Solutions LLC. All Rights Reserved.