It's not about delivering poor code quicker, it's about delivering
better code quicker. Coding starting with a well designed "test" (a
predefined result) then building up code to satisfy that test. But
only coding what's required, not coding isn't in use yet.
What is left out is the stuff that is often inserted up front then
found to be not needed or incorrect. So, there's no coding for "future
needs". In the case of traditional design where the first iteration
might delivery the inventory module but not the purchasing or order
entry module, the inventory module is built to do what it needs to do
and nothing more - the hooks and additional "stuff" that we might
traditionally have added when coding to cater for how we think the
future modules will integrate is simply not done until those modules
are scheduled to be added on the storyboard.
The logic for this is that the additional work of adding them when
required is no different to the amount of rework that normally happens
when we find that what we anticipated was required has to be removed
or altered - often affecting our original work as well.
Another way to think of it is to build methods that solve the cases we
know about rather than trying to build "super methods" up front that
will handle the cases we know about and all the cases we can imagine
might be needed. A lot of code might be written for cases we will
never actually use, and the cases we anticipated might require rework
when we have an actual real life case to be handled by our code as we
didn't anticipate it quite right.
As to the pair programming, I understand other people misgivings, but
have a different take on what pair programming is and how it works. Up
front, let me say that I have not practises it in a formal sense, I
just imagine it working a bit differently to two people "writing the
code". It seems to me more like a pilot/engineer or pilot/navigator
arrangement where on person handles the mechanical aspects of the
coding and someone else works with them in the "where are we
going"/"how does it fit in" kind of picture.but perhaps a bit more
than that. I imagine some back and forth about "why are you using a do
while loop, a do until would be better in the case because..." type
discussion or perhaps it might be - try using this technique instead
of that technique to solve that code problem.
The few times I've written code with someone right next to me that
understands what I am doing enough to suggest changes or alterations
as I write the program has been pretty interesting - it does seem more
productive (and it's way more enjoyable), but it was not any kind of
formal pair programming project, just a case of needing a program
knocked up as part of something else we were working on.
I think it's a challenging concept and would be really interested in
trying it. I think one of the biggest hurdles would be that it
requires people to really put aside their egos when coding.
On Wed, Aug 31, 2011 at 3:23 AM, David Gibbs <david@xxxxxxxxxxxx> wrote:
On 8/30/2011 9:48 AM, Buck wrote:
Agile appeals to me because it shortens the release cycle from years or
months to weeks. I'll still do rework, just like the waterfall code,
but instead of tearing up 6 months of work, I'll only have to go through
2 or 3 weeks worth.
True ... but (at least in my observation) you'll be doing the rework much more frequently ... because you your focus for the initial development was too specific.
Nothing annoys me more than someone taking the attitude "I'll code it poorly now, so it will work, and fix it up later". Better to write your code to accommodate functionality that you KNOW is going to be in the next iteration.
Refactoring is a strong attribute of the Agile / Scrum methodology ... RPG & Cobol don't lend themselves to automated refactoring (unlike Java).
david
midrange.com
