Previously
This is the seventh in a series about TDD’s value to humans, following
- Keeping my job, in which I lost my manager’s trust,
- A last-minute feature, in which I regained some,
- Deadline pressure, in which I earned quite a bit more than I’d started with,
- Continual delivery, in which the circle of trust grew to include our Operations team,
- Fail-safe, in which we were always deploying soon, and
- A big project, in which we delivered an 8-month project with minutes to spare
Cosmic justice (again)
Right when our velocity had tanked (see “Change the plan” in A big project) and we were scrambling to get back on track, it came to light that our system would need to provide some as-yet-unspecified new behaviors in order for our coworker Murray to deliver his project. With a deadline looming, was there any way we could defer the new work? Nope. Murray had a deadline too — and it was the same as ours.
I invite you in this particular moment to enjoy Jim Gaffigan on what it’s like to have four kids.
Why me?
I was invited in that particular moment to join the discussions between Murray and Dan, an expert stakeholder. But if I was already unsure I had the time, energy, and cognitive capacity to hit my own deadline, then I had approximately zilch to spend on someone else’s. No matter how much I liked them and wanted to help, I couldn’t afford to get involved in what would necessarily be spiraling discussions about requirements, scope, and feasibility. Even if I managed to sit those out, the mere thought of having to interpret the intent of a design document made me clutch more tightly at my mental wallet.
Dan’s manager, looking to break the logjam, generously offered me a couple weeks of Dan’s time. But borrowing developers on short-term loan with the expectation that they’ll improve overall team throughput rarely meets expectations. Setting aside whether it’s reasonable to assume that human productivity is additive, there’s too much for a visitor to learn in a short time — programming language, tools, habits, problem domain, context — before a potential payoff. Having recently hired several developers, we’d seen ourselves get a bit slower until they mostly knew when and how to trust themselves to work safely and productively. That had been taking 3-6 months.
Maximize the amount of work not done (by me)
I continued to think through the offer, though, because if there were an exception, it’d be Dan. He was deeply familiar with our system’s purpose and behavior from having previously worked in our department. He was well versed in our primary implementation language and very comfortable writing unit tests. And, as with Murray, I knew I could trust him.
The decision came down to whether I could figure out what to have Dan do that would help me help Murray. As soon as I figured it out, I accepted the offer and gave him this assignment:
- Determine exactly how my product needs to change to do what Murray’s product needs, leaving for later everything that can possibly be left for later.
- Involve me not until you’re done.
- ”Done” means a specification in the form of failing test cases.
Not only did Dan know everything he needed to know and do everything I needed him to do, he did it superlatively. I expected to need to ask about the intent of a test or two, but his spec was crystal clear and evidently well thought out — including a few assertions that he’d decided to comment out because the wished-for behavior was tricky to implement and safe to defer.
Mission accomplished
Smart fellows that they were, Dan and Murray knew it was in our shared interest to assign me the least thinking and typing possible. They nailed it. I was able to stay completely focused on my project until Dan’s tests appeared; I spent a couple afternoon hours getting them to pass, knowing Murray would be getting precisely what he needed (and soon, because we were always delivering soon); and by morning I was once again completely focused on my project.
Given how close we came to missing our deadline, a few contiguous hours must have been all I could spare. We made it. So did Murray.
When offered Dan’s capable development help, we were able to accept it because we had a creative way to parallelize his efforts. And because we had a test-driven way to take advantage of his expertise, all of us met our commitments.
Conclusion
If there was some other situational approach we could’ve taken that would have cost the business less or delivered more, I sure as hell can’t think of it.