Pathfinder Blog
Topic Archive: Pair Programming

Testing

Scot Witt, Thursday, May 15, 2008 @ 4:22 pm

Let's have a little more compassion for the QA Team, eh?

Well, actually, the Design Team disguised as the QA Team.

The little frustrations, system and function failures result in a lot of dog-kicking, huge antacid and alcohol intake and a lot of whining. I begin to understand how little-person tossing may have started down under a few years ago. Obviously QA Teams at the pub got this trend started.

The academics have broken testing up into five or six TLAs (Three Letter Abbreviations designed by Consultants so they can charge more and use more buzzwords than normal people). You got your UAT (User Acceptance Test), your Unit Test, your Sanity Check, your boundary test, your Automated Regressive and Non-automated Regressive series (this means high school kids who click and chew gum while re-Ghosting machines) and on and on.

These labels are obviously created by people who don't do testing.

Us testers use language you shouldn't put on a blog.

This blog started because I had to do a complicated test three times today before I got the dang thing right.

I wrote the test script, had to change it four times because it wasn't really testing what I wanted it to test when I was writing it yesterday. Funny thing. I had the developer who created the function look it over for me. He said it was fine.

But each of those rewrites was one to three new database entries.

When I had it right and came to the end of the second phase of the three part test... the application didn't do what I wanted it to do. Totally unrelated to the test. ARGH!

I know.

You've been there, done that and have the tee-shirt.

Come to think about it, Our PM owes me a tee-shirt. 3XL, Ron, I've lost 45 pounds since 4/4.

Before I threw my laptop at the wall, I calmed myself by repeating the Tester's Mantra: If I didn't find it, the Client would.

The thing is, I don't mind writing Test Cases or even test scripts. I find writing them an interesting challenge. I also find doing them drudgery, akin to the constitutional prohibition against cruel and unusual punishment.

I wish I could get into the spirit of a real QA guy who thinks about these tests creatively and with wild abandon. You know, the fellow or gal who can think like a crazed end user ready to pounce on my poor application with abandon and relish.

Such folks are a treasure.

But with a small team, the lack budget for QA resources and the need to test major functionalities of a complex application, we Business Analysts, Information Architects, Project Managers and Receptionists will continue to click, type, spell check and screen capture.

And moan, groan and whine.

But it's gotta get done.

Oh, for the days when the BA and QA Lead managed the process and others did the work...

Topics: , , ,

tech development Tech Development

Another Way to Pair Program: Generating Requirements

Scot Witt, Tuesday, May 6, 2008 @ 12:13 pm

The CTO (Chief Technical Officer) tells the BA (Business Analyst- me) and the IA (Information Architect) to pair program.

He's our boss' boss.

He's our Agile ubermensch (mensch is a Yiddish-Middle German word meaning, in this context, expert, coach, guide, all around super star; I don't know if it is in Modern German, but our CTO will tell me, he's fluent in German. I took Latin and Spanish).

We gotta do what he says.

I whine that I write faster than the IA.

The IA complains I can't do wireframes as fast as he does (true, VISIO isn't as easy as it looks, kids).

We are despondent and snarl at each other. Pitiful.

An idea.

How about we split the requirements in half. I pull the ones I wanna do, the IA grabs the more visually oriented ones. We write 'em up, do the wireframes and then have the other edit and comment on the other's work while we collaborate on the items we need to.

It allowed me to spit out the bug repairs like a machine gun and freed our IA into drafting wireframes and workflows he needed to do without slowing me down. While we edit the other fellow's stuff, we find small errors, ask some questions and significantly improve the requirements without turning them into novels.

The benefit was to the Developers who had very spiffy, concrete, succinct and directed requirements before the iteration started. They had time to read them, ask questions and begin their design work. The client was able to read them and sign off early making the sprint kick-off run smoothly.

The CTO gave his blessing.

And yeah, I started numbering the dang Business Rules to help the Developers, even though everything I ever learned about writing tells me non-hierarchal/unrelated lists should be bulleted. But it helps the developers refer to specific rules and my sense of technical writing dos and don'ts can suffer this arrow of outrageous fortune.

The Developers were not impressed. They like numbers. Especially ones with decimal points.

Turns out the PM (Project Manager) even likes the IBM-concentric deep diving numbering schemes of the 1970s. There's no accounting for taste, is there?

But I don't have to like it, do I?

Topics: , , ,

tech development Tech Development

Pair Programming with VNC

Dietrich Kappe, Thursday, September 6, 2007 @ 5:25 am

A little Agile to go with the Ajax...

My four commandments of Agile Development are:

  1. Short iterations
  2. Pair programming
  3. Test driven development
  4. Continuous improvement (sprint reviews, etc.)

I have strong opinions about continuous integration and related agile practices, but those can be negotiable. Not all methods are appropriate for all teams, projects and clients. But the four above allow each team to find its own velocity and process.

Offshore Pair Programming

But how to do pair programming with an offshore team? There are a number of inherent problems with making this work:

  • Not enough schedule overlap with places like India and the Philippines
  • Uneven network performance
  • Language difficulties
  • Telecom difficulties

None of these issue is insurmountable. If you are offshoring significant software development, you likely operate at a scale where you can afford decent bandwidth, firewalls and telecom systems. Don't skimp here by trying to run Skype on already overloaded laptops. Give each onshore and offshore developer their own direct dial number.

For the schedule overlap, I've found that a 4 hour overlap is sufficient, though 6 is better. For a twelve hour time difference, one team can stay late while the other gets in early. Onshore and offshore can alternate on who gets in early, etc. Or you can go with the former Soviet Union (FSU), which has less of a time difference.

Finally, language difficulties can be a problem whether you are practicing pair programming or not. Rather than exacerbating the issue by placing an emphasis on verbal communication, in my experience it actually improves communication  between team members by getting them more used to one another's accents. Immersion courses work for teaching foreign languages, why should it work for the less difficult task of understanding a foreign accent?

How to Pair

Now in an onshore setting, my company rarely practices the "one mouse, one monitor, one keyboard" brand of pair programming. Tasks are shared, the developers sit at one desk and collaborate, but they have their own laptops. This differs a bit from the traditional definition:

Pair programming requires two programmers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing: for example, while one types in unit tests, the other thinks about the class that will satisfy the test.

The person who is doing the typing is known as the driver while the person who is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour or after a unit test is made. It is also suggested to switch partners at least once a day.

But in an onshore/offshore situation, where the partners are tied together by a phone line and a VPN, the shared workstation is really the only feasible way to make pair programming work. Anything else, phone, IM, email, even video conferencing, is awkward and unproductive.

In my firm, we've tried various approaches to shared workstation pair programming, such as Windows Remote Desktop, but we've come back to the one that performs the best and presents the fewest obstacles: VNC (Virtual Network Computing). VNC basically (see here for a version that is efficient for slow connections) gives you remote control of a desktop. That's from and to pretty much any Windows and Linux/Unix/X11 machine.

We've tried the approach of having one developer hooking up to the other developer's laptop, but that leads to poor performance. A far better approach is to use a powerful server class machine and have both developers access it via VNC's screen sharing. (See here for one group's VNC setup, though they do it locally.) The idea of using a powerful server pairing station is nice. It recognizes that running something like Eclipse or Visual Studio, and application server and VNC is somewhat too heavy a task for a humble laptop.

Combined with periodic offshore/onshore personnel visits -- which build up trust between developers -- the shared workstation model of pair programming is something I would encourage anyone combining onshore and offshore development teams to try.

References

Technorati Tags: , ,

Topics: ,

agile ajax Agile Ajax

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

Blogroll

WordPress

Comments about this site: info@pathf.com