Previously

This is the last in a series about TDD’s value to humans, following

1. Keeping my job, in which I lost my manager’s trust,
2. A last-minute feature, in which I regained some,
3. Deadline pressure, in which I earned quite a bit more than I’d started with,
4. Continual delivery, in which the circle of trust grew to include our Operations team,
5. Fail-safe, in which we were always deploying soon,
6. A big project, in which we delivered an 8-month project with minutes to spare,
7. Win-win, in which we helped another project hit the same deadline,
8. No secret, in which people oddly found the reasons for our success disappointing, and
9. Thwarted, in which we almost reached a new level of collaborative development

Is there a doctor in the house?

People who rely on the outcomes of software development work, but who have not experienced firsthand what it’s like to do that work, sometimes present with a disheartening cluster of chronic symptoms:

• They want to do something to help bring about an outcome
• They see some simplistic knobs they could turn
• They don’t see the costs of turning those knobs, or notice the less visible knobs, or consider abstaining from knob-turning altogether

People exhibiting these symptoms might, for instance, ask a developer to spend less time testing. (Note that they wouldn’t be caught dead on the record instructing anyone to write fewer tests, but that’s exactly what they’re wishing for.) This particular simplistic knob appears to provide a way to trade quality for speed. If we rarely have shortfalls in quality, and we’re perpetually understaffed, then let’s turn this knob just this one time. Oh, and while we’re presuming that developers don’t spend their time wisely, let’s also presume that in any given unit of time they can always find a way to accept more work.

By contrast, managers and customers in good software health know that developer productivity is nonlinear. Even when solving relatively well understood problems, time can’t usually be reclaimed from test-driving and redeemed for more stuff done over any horizon longer than a few lungfuls of overly conditioned air. The outcome of attempting to trade quality for speed is often not only to have traded quality for nothing, but also to have undermined the hard-won basis of the attainable speed that had once been attained. (And “productivity” is itself a questionable construct when the goal is ostensibly not to maintain busyness, but to solve problems for humans.)

Is there an epidemiologist in the house?

Quite a few folks with other goals do nonetheless exist, as do those who come to poor knob-wiggling conclusions via faulty premises: people who don’t begin to understand the nature of software development work, don’t begin to imagine that their lack of understanding could possibly hinder the outcomes they wish for, don’t prevent themselves from intervening roughly and habitually in sensitive systems, and cause pain for themselves that perhaps only hints at the pain they cause others. I worked with (and for) many such people at the organization featured in this series of stories. Their broad and deep misunderstandings of the costs and benefits of TDD and of software development in general — and my overall lack of success in reversing or otherwise overcoming them — ultimately limited my effectiveness in my various team roles. But everything I learned along the way is mine forever, to keep and to share.

Retrospective

We had a great run. Along the way, while reviewing my performance, I summarized it thus:

Test-Driven Development has become thoroughly entrenched as a standard practice for $OURPRODUCT Engineering. The dividends, many and profound, are difficult to completely quantify. Nonetheless, three overall patterns are striking:

1. We’ve reversed the usual signs of software aging. As typical projects expand, the risk of change increases and the pace of development therefore slows; as $OURPRODUCT’s test coverage expands, the risk has decreased and the pace has accelerated. With TDD, we can safely develop complex, invasive new features (like support for an archaic database system’s not-exactly-identities) and trust them to work as designed without breaking existing code.
2. We’ve fundamentally changed our relationship with Operations. They now trust us to ship working software because they understand how TDD works. We’ve taken advantage by releasing monthly (up from quarterly), which controls the rate of change, ensures that new code is always production-ready, and maintains our sharp and careful release habits.
3. We’ve identified a new paradigm for collaborative development at $COMPANY. The situation: $OTHERPROJECT1 needed $OTHERPROJECT2, $OTHERPROJECT2 needed new code in $OURPRODUCT, and $OURPRODUCT was laser-focused on that $ARCHAIC_DATABASE_SYSTEM, leaving me zero time for requirements and design discussions with $OTHERPROJECT1. They generously offered a developer on short-term loan (a week or two) who happened to understand our product and had the needed technical skills. The paradigm: I accepted the loan on condition that it result in a set of test cases for our test suite. This forced all the discussions to happen upstream where they cost me nothing, made efficient use of the loaned developer’s cross-silo expertise, and delivered a simple, unambiguous spec which took me an hour or two to implement. $OTHERPROJECT2 and $ARCHAIC_DATABASE_SYSTEM both shipped on schedule, thanks to TDD.

In summary, the cultural shift to Test-Driven Development has resulted in less risk, more intelligent use of existing resources, and more agile reactions to the changing needs of the business.

Conclusion

On our own, in a little corner of a big company, we created half a humane workplace. If our efforts had been recognized and reciprocated, it could have become a whole one. The pride I always felt in our work, combined with the pain I frequently felt while doing it, led me to become a software development coach. I want to help people understand how this kind of work works, and how it can be done better, because I want our lives to be filled with less pain and more pride.

And that, as fully as I can tell — and have now fully told you — is the human value of TDD.