Inspiration for test-driven design?

What could possibly inspire someone to take test-driven design (TDD) more seriously? I can only tell about what kind of experience has inspired me: (1) the act of watching someone doing TDD with dexterity. (2) Observing the quality of the outcome in relation with its requirements and specifications. (3) Checking out the pace of work in the professional life of the person in (1) —mainly, that she has a full life after work hours.

I usually tell a story from my first encounter with a TDD-like mindset, that day I knew that software design and computer programming was much larger and distinct —orders of magnitude distinct— than I had understood at the moment (and I was already a software engineering practitioner, with a computer science degree). I leave the full story for other time, shortly: it was about 1998, when many of us were talking about how bright the software design world would be with the “Unified Method” and drawing UML —not named so at the time— in large screens, and full applications automatically generated out of those drawings. Then came that guy, Kent Beck, talking about what I thought was a kind of “heresy”: test-first programming. The point is that he was not just talking about it, I saw him doing it, with a pair-programming partner, in a presentation in front of many. They wrote the code, test-first, and ran a demo of a small application using Smalltalk, in minutes. And the application design had very relevant quality properties of coupling, cohesion, separation of concerns, layering, that we know are important.

Moreover, TDD is just one among a set of interrelated values, principles and practices. There are enough to unlearn, re-learn, and learn that re-launch my professional career, from time to time, is a justified idea. For me, there are inspiration in the idea that transforming my professional life is in my very own hands; that is, in particular, in the possibility of changing my very own professional mindset. Fortunately, there is ample room if someone choose to do that, because software design and computer programming is much larger and deeper than usually thought. If our current fraction of theory and practice about software design and computer programming enable us to be part of this connected systems revolution of today, how much more we will able to do if we regularly reassess our current mindset?

I have seen programmers looking for case studies to convince their management partners about the goodness of TDD. They might need acquisition approval for books, tools, maybe external coaching assistance, so they certainly could benefit from case studies that show how TDD is good for the business. But the more compelling business cases I have seen is not just for a single practice like TDD but for the pattern language of interrelated practices under the adaptive way of life. If they are looking to convince management about something, perhaps they should strive for a more compelling business case; for example: The Economics of Iterative Software Development: Steering Toward Better Business Results.

Fortunately, free aspects of TDD can be practiced without any approval because those aspects are part of doing their job, a job that management already expects they fulfill well. Therefore, there are effects of TDD that can be shown as business benefits, not in the somewhat abstract language of a case study about what others have done in a foreign context, but as tangible business benefits in their own context. With this concrete supporting evidence, they could be in a much better position to convince anyone to provide more management support.

«How do I sell my executive team on doing this stuff? Don't. Just do it. They don't know what you're doing anyway» —Jim Highsmith

Comments

• Anonymous
  May 29, 2013
  Interesting and informative. Thank You.