On 7/20/2018 5:17 PM, Richard Schoen wrote:
Try pair programming for a few days and you will definitely flee for the hills.
I said Alt-F4, not Shift-F4. Let me be the left hand for a while and you be the right so I can work on my dexterity.
In the 80s (yes, the 80s) I worked in a tiny office with my
boss/manager/fellow programmer. The term 'pair programming' hadn't been
invented yet - the consultants were making money by pushing other
'silver bullet' techniques. I digress.
My boss and I were doing genuine, effective, and brilliant pair
programming, and we didn't share a keyboard, nor a 3277. We shared our
thoughts. Programming is about thinking, IMO, not typing. The pairing
that XP talks about isn't about the keyboarding, it's about the ideas,
the concepts, the architecture.
He'd be working on a program and say something like 'this record has an
array of monthly sales that we need to xfoot - I was going to map the
array in the I-specs; what do you think?' I'd throw out some ideas and
we'd spend 30, 90 , maybe 120 seconds going back and forth and he'd
write what he felt would be the best compromise for this specific
situation.
The best and most important part wasn't the consensus; it was that the
both of us were versed in the decision making process as well as the
actual implementation. In six months, either one of us could maintain
that code because both of us were 100% aware of how it got to that place.
We didn't have a formal role swap between who was the keyboarder and who
wasn't; usually we were both working on related programs at the same
time (both keyboarders on separate terminals.) No, we didn't have
discussions about every routine line of code, but we had enough talk
that we could keep up with what the other was thinking and doing.
I don't work in a capital-A Agile workplace, but I've seen plenty of
consultants wandering through unironically promising that rigid
adherence to 'The Agile Bible' would be our saviour. That such
consultants and such mindsets exist isn't a reason to throw out the key
points of agile programming.
Even if you (like me) don't work in a truly agile organisation, you can
still get benefit from the ideas that spawned the Agile movement.
Software changes - must change - so write the code so that it's easy to
change. If you write automated tests, it's easier to change the code
because you guarantee that existing functionality didn't break. If you
pair up, you share what you know and learn what you don't - this makes
the code easier to change by spreading the expertise. If you release
early and often, the code gets better because the user feedback loop is
shorter. You don't need to do All The Agile Things Or Else - doing even
one makes for a better code base.
midrange.com
