Doer vs. Talker: Working Software over Comprehensive Documentation

Posted by Geoffrey Wiseman on Jan 16, 2008 08:10 AM

Community

Agile

Topics

Delivering Value

Tags

Business/IT Alignment ,

Agile Manifesto

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.

1. Back to top

   You must walk a fine line

   Jan 16, 2008 10:34 AM by Ryan R

   It's important to walk a fine line between talking and doing.
   
   Some of this is cultural. Working in a large Federal Consultancy has shown me how easy it is to succeed without really delivering anything. In places like that, talking is valued over doing. "Doing" is pushed down to junior level resources who have little experience and receive almost no guidance. As long as the revenue line goes up, the senior folks aren't concerned with how successful or unsucessful an engagement is.
   
   Some of this is human nature. I think many technical folks want to get the problem and its solution laid out all before hand. This is a rookie mistake. Wasn't it Fowler who stated that a designer's riskiest project will be the second one they design? It's due to taking lessons learned on the first project and attempting to apply them, holistically to the second project, from a design and architecture perspective.
   
   I feel that finding the right balance comes with experience. Up front design is good! It's just that eventually, you have to stop talking and start doing and produce something. A good manager or technical lead knows, based on experience, when to stop design and architecture and begin implementation, regardless of the completeness of a design.

   Reply

2. Back to top

   Re: You must walk a fine line

   Jan 16, 2008 12:54 PM by Konstantin Ignatyev

   yes, but I think balance should be tipped a bit towards talkers because when doers run the show over short period of time they tend to produce unmanageable solutions which need to be scrapped. Before they scrapped those solution inflict much pain on the people who understand that if doers just took 0.1% just to talk over what they are going to do and communicate it even to themselves it would not be that bad.

   Reply

• Older >