Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Doer vs. Talker: Working Software over Comprehensive Documentation

Doer vs. Talker: Working Software over Comprehensive Documentation

In Are You a Doer or a Talker?, Jeff Atwood of Coding Horror echoes the agile manifesto's 'Valuing working software over comprehensive documentation.'  Noting an article by John Taber, Atwood draws parallels between transportation studies and transportation construction projects. Just as transportation studies deliver documentation, rather than transportation, so can the planning, design and discussion of software obscure the job of building software:

It's an easy conceptual trip from building bridges to building software. In software, some developers take up residence on planet architecture, an otherworldly place where software is eternally planned and discussed but never actually constructed. Having endless discussions about software in a conference room or mailing list feels like useful work-- but is it? Until you've produced a working artifact for the rest of the world to experience, have you really done anything?

In the comment thread below, Mike points out the dangers of dichotomies.  Some imagine that the manifesto's emphasis on some elements means the other elements have no value, but this isn't true.  It's not that documentation, architecture, design, and discussion about building software don't have value, it's just that working software is the goal, and if producing ever more documentation is getting in the way of that goal, it's time to adjust priorities.  As Jeff Atwood concludes:

So that's what you have to ask yourself: are you a doer, or a talker? Ideally, you'd be a little of both, as I've said many times here. There's certainly value in some discussion and planning on your team. But if you must pick one or the other, try to err on the side that produces useful, working code

Even so, the extensive discussion thread imply that finding the right balance between talking and doing is an art that still causes much frustration in the lives of developers.

Rate this Article