Joe,
I understand where you are coming from. As I said in another post... its
not for all situations. Lots of business applications have well defined
specifications (I know, laugh laugh, but its true), or you are coding to
some sort of standard process that is a matter of just pounding out the
necessary lines of code to make it work.
Its not about typos, the compiler will catch those. Its about the bigger
picture. Programs can become complicated very quickly, and very little
code written hits the deck without any bugs. Cases that weren't thought
of where two pieces of code integrate, cause and effect with other parts
of the system. Sometimes having that set of eyes and other set of
experience can save hours or days of trouble shooting and bug hunting.
Using a variable with similar but just slightly different context can
cause a headache. You become so close to the code that you begin to see
what you "think" you see, not what is really there. This happens no
matter what the quality of the programmer. You don't always take the
right approach the first time, you always have code that you later wish
you could refactor. Iterative development is supposed to make refactoring
easier and not such a loaded and haunted idea. Its ok to admit we are
human when we code, no one is perfect. And if we are honest about the
amount of mistakes in our code, either caught by ourselves during testing,
or by the users in production, I think you'll begin to see where an
integrated approach between two programmers can come in handy. Its not as
simple as one person coding and another person just sitting there
watching. Its way more involved than that. To hold it at arms length
like that is not fair to the practice of pair programming, or honest about
what its application is or should be.
Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777
Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces+bmartin=c-sgroup.com@xxxxxxxxxxxx
08/30/2011 09:32 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc
Subject
Re: Agile Development, Anyone?
On 8/30/2011 7:32 AM, Bryce Martin wrote:
You're missing the point of pair programming. Its about tackling a
problem with 2 heads, cutting the thinking time down, and getting a
product iteration out. We can make claims about super programmers not
benefitting and yada yada yada... but if a super programmer is working
on
a sufficiently hard problem then pairing with another super programmer
would make that problem much easier to tackle. This works especially
well
when needing to melt two areas of expertise. Its not about syntax and
style... that is what the language and style guides are for. Its about
solving a problem with as few bumps in the road as possible. Two sets
of
eyes means automatic double checking of the code, auto code review as
someone else had said.
I get all that, Bryce. It just doesn't see effective to me. Well, yes
and no. You actually make two separate arguments: two heads for design,
and two heads for coding. The two heads for design I understand but
frankly I have always had joint design sessions where we discuss the
architectural issues and the design points. They are unstructured and
loud and a lot of fun (and occasionally a bit of heat as well). And
then eventually we come to consensus and we move on to programming.
For programming though I just don't get the concept. One person sitting
while another types code? If you make enough errors that another
full-time person watching you code is cost-effective, then I submit that
perhaps programming isn't your calling. Think about this realistically
- while you are programming in a day, how many unforced errors do you
make that someone can catch just by watching you type? Is it worth
another full-time programmer as good as you to sit and catch those? In
other words, do you make so many typos in a day that it takes you a
whole additional day to fix them?
On the other hand, if you're doing design decisions during programming,
then your design sessions weren't effective. I mean, how many design
problems do you need to solve during your programming that you need help?
Maybe I don't get it. It seems to me that a lot of these "agile"
techniques are about designing on the fly, and refactoring, and meeting
changing requirements, and that upfront design is impossible, and that
you can only develop applications effectively in a reactionary mode.
Sort of like "we have to pass the bill to see what's in it". I don't
buy that. Maybe it works in games or something, I don't know. But to
me top-down design is still a fundamental requirement for business
development.
But hey, that's me. I'm old. I like RPG. What can I say?
Joe
midrange.com
