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.
You must walk a fine line
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
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015