![](https://secure.gravatar.com/avatar/1621df79585db64906e910ab06c58c47.jpg?s=120&d=mm&r=g)
Cory Dodt wrote:
Resolving a bug includes gathering requirements and building consensus, but building consensus goes much faster if there's an implementation handy to discuss. Even a quick hack is useful as a discussion point. A very common scenario is that a quick hack is eventually refined into a unit tested, UQDS-vetted implementation. However, a hand-waving discussion never is.
Call me old-fashioned, but what you are describing is the difference between design-free-hacking followed by iteration, and actually designing something. You know, all that waterfall stuff. I know, its not fashionable right now. Seriously, though, its too late at the review-of-nearly-working-code. There's too much pressure to incrementally fix it, and at least one participant will have a sense of ownership in something that might be a country mile from the best solution. I know its easier to design when you can meet each other and use a white board or just scribble on paper, but its still entirely possible to use words. So - I disagree. I'm quite happy to hand-wave, and to listen to my colleagues' hand-waving. If it communicates design ideas - and requirements - before any wasteful coding, that's good. Honest.
Still, things get fixed when someone fixes them. It falls on the person who needs them fixed to do so, no matter whether you're talking about software or rain gutters.
Hmm. You sure it doesn't happen after the prioritisation meeting and we all get our steer? James