Previously
This is the eighth 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,
- A big project, in which we delivered an 8-month project with minutes to spare, and
- Win-win, in which we helped another project hit the same deadline
Our somewhat interesting behavior
Our track record of delivering working, valuable code every month began to attract some mild curiosity. For most teams, the organization’s barriers to releasing production code had the effect of encouraging them to go to production less often with only the planned changes. We didn’t see that as an effective way to manage risk for — or add value to — code with test-driven properties. To suit our context, we chose the opposite approach: go to production more often with whatever was ready. Onlookers were curious to note that this game we were all playing could evidently be played so differently without immediately and visibly losing.
Our very interesting behavior
When we delivered a project on deadline while supporting another project being delivered on deadline, our strange approach (whatever it really was) looked much more like a winning strategy. Onlookers who might have dismissed our monthly release-what’s-ready cadence as “undisciplined” might have felt motivated to reevaluate. Our previous track record plus a successful project attracted much more curiosity.
What about QA?
One question I’d get asked was, how did our QA people validate the changes we were making so frequently without strictly adhering to a plan? Surely this was taxing for them. How did we arrange their work to be able to sustain our pace?
We didn’t have any QA people. Our tiny team on a tiny budget had learned, of austere necessity, to survive without. Our software had wide-ranging security implications. We had to work in a quality-assuring way at all times. There was no QA bottleneck because there was no QA phase.
This was a surprising answer. Nearly all development teams had “QA people” (whatever that even means). I would occasionally get an offer of someone for a few days, but I never knew what to have them do. What could they manually test that we hadn’t already automated? What could they exploratorily find that we hadn’t already found? To be polite, and just in case, I would accept these offers, summarize what was new lately, and point them at the GUI. We got very little value from this arrangement. If we could have added a permanent team member with complementary testing expertise, it might have been much more valuable. Still, not having someone didn’t seem to be impeding us.
So what was our secret?
It was also an intriguing answer, because it appeared to take the form of “doing more with less.” Everyone always needed to be doing more with less. Their next question was, what were we doing to obtain this level of quality, speed, and predictability?
Most of our quality and speed came from TDD. Most of our predictability came from test coverage and Scrum-style velocity. But TDD would have been difficult, and velocity-based predictions would have been disappointing, if we hadn’t first rescued our code just enough to where we could incrementally improve its health over time. What was it that we were doing? Being skilled, disciplined, and patient.
Unable rightly to apprehend
I hadn’t expected this to be a surprising answer, so I was surprised by the responses it provoked. Faces that had been pumped full of anticipation deflated. “We can’t scale that,” said one. It hadn’t occurred to me that anyone could be hoping for easy actions and fast results to what I knew to be hard problems. Charles Babbage famously rebuked someone for asking an incoherent question about his computing machine; I was seeing what looked like an incoherent reaction to my answer about our software development machine.
Conclusion
How could I account for so rapidly having transmuted respect for our outcomes into disappointment in our methods? Not knowing, I had to wonder. Practicing TDD had expanded our sphere of influence greatly and made us more effective in many ways. Would the trend continue?