It’s been 3 weeks, 450 man-hours and 6,880 lines of code, and it’s done.
Working as a developer for a call center, I often see some interesting and rather challenging projects. The latest is no different. One of our largest clients (a major bank) asked us to develop an application to assist in processing credit card applications.
While the original request seemed simple, the final specification though was far less simple. A highly dynamic, intelligent, and multi-language application was needed. It’s been close to three months since development started, and 3 weeks since the current major update was started.
Weighing in at 22,880 lines - this is a rather large application, highly dynamic, fault tolerant, and has complete multi-lingual support. Built in VB.NET and based on the .NET Framework 2.0, this is the largest .NET application I’ve seen though to production.
Not only was this one of the larger .NET applications I’ve worked on, this is also the first project I’ve worked on using a Pair Programming methodology. I joined the project about 1/4th into the initial development, and since then I’ve been working extensively with Laura to complete the project.
After reading about the methods used by High Moon Studios, Laura and I decided to attempt pair programming. In March when this project was first mentioned, we decided this would be the ideal project to go forward with this experiment.
To ease development, I acquired an HP desktop (with a few upgrades) and Laura provided a pair of keyboards and mice for use as a development workstation. With two developers at a single computer, the boost in productivity is remarkable. While I always believed that pair programming could not add significantly to productivity, the quality and speed of development of this project proved me wrong.
With nearly 23,000 lines of fully optimized code, and early testing showing remarkably few bugs, the short development timeframe makes this a remarkable project. When this project started I wouldn’t have dared to dream we could achieve so much, so quickly.
Looking back at the progress made, I’m now a believer that that pair programming is the way to go. While I still have many reservations about the concepts of Extreme Programming, at least this aspect is a good idea.
Our latest project involved four (five in total, on and off) of our team and we managed about 65,000 non-comment lines of C# and I don’t want to know how much PL/SQL over a three month window. It was less than a fun excercise but man it was amazing to see what we could accomplish!
We’re now in the midst of implementing agile techniques - I can’t wait! I’ve never had a chance to do any serious pair programming, but of the few times I’ve participated like that at work, it seems to work really well.
Did you find any problems/hurdles whilst pair programming?
Al.
June 17, 2006, 9:43 am
Al, that’s quite an accomplishment, impressive.
The pair programming went a fair bit smoother than I expected, but there were a couple interesting lessons:
1). Carefully consider who you partner with, it’s important that your skills complement. It’s also quite important that you agree on smaller details such as style - if both developers don’t agree on design and coding styles, it can make the task a fair bit more difficult.
2). Be respectful of others while pair-programming. A big part of pair programming is communication; you’ll find yourself talking all day. If you share an office, keep in mind that you’ll end up making enough racket to disturb everybody else. At work, I share an office with 3 other developers, when two of us pair up on a task; it serves as a real distraction for the other two. So my solution was working remotely from my home office. If you’re working in a shared environment, something to keep in mind.
3). While working in a pair environment, distractions are less important. This one I found interesting, each developer drives the other, so when I distraction comes up, both developers help to re-focus each other. This is important as you’ll find that you spend a good bit more of your time not writing code, but discussing design issues. Thanks to driving each other, switching gears is surprisingly easy.
4). Don’t work long days. After 12 hours of pair programming, you’ll find yourself becoming a bit ’slap happy’ - the temptation to tap the arrow keys while your partner is busy typing is remarkably strong. This method drains you more quickly than working alone, so you’ll find that you’ll reach the point of diminished returns sooner.
All in all, I was quite happy with the result of our experiment, and I fully plan on looking at some other agile methods to see if there is anything else that looks promising. Once you have the chance to use this method on a large project, let me know how it goes. I’d like to hear your comments on how it worked for you.
June 17, 2006, 10:55 am
While the vast majority of my professional programming experience has been coding alone, I did have the opportunity to work on one project in a pair arrangement. The observation I made was that you really need to match backgrounds well for the pair to be effective. Even with the incompatibilities between a Windows-based C++ developer and a Mac-based Java developer, however, I wouldn’t say that we were less effective than one programmer, and at the end we had the benefit of two people who knew the module intimately.
June 17, 2006, 3:20 pm
Just thought I’d add a few additional comments about the perks and pitfalls of this method. Overall, I am extremely pleased (no pun intended ;)) with the results. I’d had mixed feelings going into the experiment, as most of my team programming experiences have been less than productive. For the most part, my reactions echo Adam’s.
1) I definitely agree that the composition of the pair team is important. In our case, we were on pretty similar footing with this project — experienced programmers with many years’ background in VB/VB.NET, but fairly new to the 2005 version which we decided to migrate to early on in the project to sidestep some roadblocks with VB.NET 2003. Other researchers (http://www.stsc.hill.af.mil/crosstalk/2003/03/jensen.html) indicate that it is most advantageous to pair an experienced programmer with a less-experienced one, but personally I’m not sure how well that would work; it seems to me that the experienced programmer would end up frustrated and the novice would end up bored. Not having tried that mix, however, I can’t discount it out of hand. For us, it was helpful that we were both pretty good at coming up with multiple approaches to any problem we ran into, and the pair approach made it easy to quickly evaluate and choose a best solution (most of the time).
2) Distractions work the other way too — not only can the pair team be a distraction to officemates, but also the constant hubbub of a busy office can quickly destroy any focus a pair has, especially if one or the other is frequently getting dragged off to check some other crisis. We were very fortunate to work for a boss who trusted our judgment enough to allow the offsite solution, and the results speak for themselves.
3) Two sets of input devices make the pair experience a lot smoother (at least until that “slap-happy” stage hits :p). Rather than playing musical chairs or sliding a keyboard/mouse back and forth, it’s so much more convenient to just be able to start typing whenever appropriate. Of course, good communication/rapport plays into this also, so that you don’t end up accidentally moving the mouse while your partner is trying to select something, etc.
4) It’s also important for both programmers to have a similar focus and intensity about the project. If one person is just interested in “punching the clock” — working a set schedule without any particular drive to accomplish anything — while the other is desperately trying to meet a goal, then there would be a lot of friction. Adam and I have a similar drive for quality (although of course not always in exactly the same areas), so that helped us work together well and served as a motivational force whenever we were nearing the end of our reserves.
June 17, 2006, 3:47 pm