Good Reads On Pair Programming

Just a quick link to this blog entry from someone who feels very passionately about the benefits of pair programming but doesn't believe that most software organizations could pull it off. He even provides 10 reasons why.

And then for the opposite view, see this, a much shorter article that argues, in rebuttal of the first, that pair programming could be for everyone.

Getting The Requirements Right

Apparently this amusing blog post was recently making the rounds at my old workplace. In it, the author imagines what designing a new house would be like if architects had to deal with the same sort of loosey-goosey requirements that software developers typically do. One of my favourite lines is "With careful engineering, I believe that you can design this [75-foot swimming pool] into our new house without impacting the final cost." As programmers, we're well familiar with the "keep the design open-ended so that all possible future requests can be done quickly and cheaply" model of thinking.

My wife Vicki is currently finishing up a contract position as a Business Analyst. While the exact particulars of that role differ from place to place, in this case it means that she splits her time between the product folks and the development team. In effect, she's the liaison between the two groups, responsible for taking "business-speak" and translating it into requirements that can be implemented by software types. It's a challenging tightrope act to pull off, because if she drifts too far in either direction she runs the risk of ostracizing the other group and thereby losing their trust and confidence. In her current environment, all of this is done in a fairly traditional (Waterfall) manner, meaning that she's spending inordinate amounts of time getting down - in writing - what the two areas of the company have agreed upon, long before the first line of code is written. And for many years, that was considered to be the optimal way to perform the requirements gathering portion of software projects.

The pitfalls to that approach are well known to anyone familiar with Agile:

• developers tend to focus on fulfilling the stated requirements rather than looking for ways to provide maximum value
• the product owners don't get any opportunities to try out what they've asked for before it's locked down, thereby missing the chance to make it better
  
• all features get started more or less at once, and any deliverables that end up being abandoned late in the project (when things inevitably run long) have usually had considerable work done on them, all of which was wasted effort that extended the project timeline unnecessarily
• there are all kinds of openings for aspects of the requirements to be "lost in translation" between the Product Manager and Business Analyst, or between the B.A. and the Programmers
• the development team is often kept at arm's length from the product team, reinforcing the "us vs them" mentality and denying both groups the opportunity to put their heads together and design something better than whatever each could come up with on their own

and so on.

When you consider all of the obstacles standing in the way of success in a scenario like this, it's sometimes mind-boggling that any traditional software projects ever succeed (about 1/4 to 1/3 do, last I checked). All you need is a Product Manager like the one being parodied in the link above, or a Business Analyst who's weak in business-speak or requirements-speak (or both), or a Developer who isn't all that good at adhering to a written specification, and you end up with a delivery of functionality that isn't going to make anyone happy... assuming it ever emerges out of the Quality Assurance phase at all, after dozens or hundreds of last minute changes have been made to it once people actually got their hands on it outside the development team.

While an iterative approach might not work all that well when designing and building a home, it has a lot of advantages when it comes to software. For example, it's a rare product person who wouldn't relish the opportunity to touch and feel a new set of features early enough in the proceedings to allow for alterations. The trick, of course, is to get such a person's head around the notion that you'll be delivering their requirements in bits and pieces (in priority order, assuming that you can get them to sit down and actually prioritize their wish list!). Some people in that role have become so accustomed to an "all or nothing" setup that showing them one subset of finished functionality incorrectly conveys the impression that it's all done! I've also heard product representatives claim that they didn't have time to review features as they came out, which of course raises the question: what in your job description could possibly be more important than ensuring that the best possible features show up in your product(s)? That kind of thinking just seems nutty to me, but I'm sure they must have their reasons.

For the last big programming job I had, I was lucky enough to have the perfect business person. The project was the creation of our Meal Planner Application, which I wrote in our basement over the 2004 Christmas holidays. And Vicki was my "customer." She had a good idea what she wanted by way of functionality, and I just kept showing her what I thought she'd asked for, until we got it right. If she'd been forced to write out in full what she imagined she'd need, before I ever started coding, I doubt that we'd ever have gotten that thing off the ground. But instead we did it iteratively (long before I'd ever heard of Agile) and ended up with a product that's still being used today, almost 5 years later. It's really too bad more organizations can't see the value in working that way.