Let’s use a hypothetical scenario to explore TDD vs. Non-TDD development and how it may affect the outcome of a software project.
The Background:
You are the lead of a small team of engineers working on an established product. One of the feature requirements for this release cycle involves a fairly significant amount of infrastructure work, which is already underway and about 40% complete. The project is currently on-time and on-budget with a release date scheduled for 3 months out. Under normal circumstances, pre-release certification consists of approximately 4 days regression and ad-hoc testing by QA staff.
The Crisis:
Thursday, 4PM: Dave, your Business Analyst comes into your office accompanied by Patti, the project manager. Both have an ashen look about them, looking as if they’d seen a ghost. Dave pipes up: “So, we just had a stakeholder meeting that resulted in a release schedule change. They want us to stop work on the new feature, revert the infrastructure changes, and at the same time pull in the release schedule by 3 months. They’re pressuring us for an estimated release date, so we’re coming to you to find out when you can have the code ready to ship.” Dave then collapses into a chair, out of breath.
Patti weighs in, saying “They’re definitely not willing to compromise on this new schedule, I honestly get the impression they’re expecting to hear a timeframe measured in days, not weeks. They were also pretty clear that heads will roll if the release doesn’t go out according to the new schedule.” Recovering slightly, Dave jumps back in, asking “So what do you think? Can we actually meet this deadline, or do I need to go home and polish my resume?”
The Dilemma:
At this point, the scope is:
- Stop development on the eliminated feature and remove all related code
- Finish any remaining features
- Prerelease testing/certification
- Ad-hoc bugfixes from certification
- Release
Watch this scenario play out in a non-TDD environment
Watch this scenario play out in a TDD environment
Leave a Reply