BT

Doer vs. Talker: Working Software over Comprehensive Documentation

by Geoffrey Wiseman on Jan 16, 2008 |

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

You must walk a fine line 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.

Re: You must walk a fine line 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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT