RE: Agile coming to our shop (supposedly)

"The pairing that XP talks about isn't about the keyboarding, it's about the ideas, the concepts, the architecture."
The idea, concepts and architecture are the goals, but chaining two devs to a single PC are the means to that end.

The Pair programming link on the Extreme Programming wiki page gives you this definition:
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator,[1] reviews each line of code as it is typed in. The two programmers switch roles frequently.
https://en.wikipedia.org/wiki/Pair_programming



-----Original Message-----
From: Buck Calabro [mailto:kc2hiz@xxxxxxxxx]
Sent: Tuesday, July 24, 2018 10:28 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Agile coming to our shop (supposedly)

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.

--
--buck

http://wiki.midrange.com
Your updates make it better!