Adventures in Agile Development – Paired Programming

I’m going to try something different today. I’m going to attempt a story. It might sound gay or retarded but I feel it accurately describes a rewarding experience of one developer working with another. So from that angle it’s interesting. If you actually finish reading in entirety and disagree feel free to comment…

Once upon a time there was a big mouthed developer named Cliff. He went on and on to his co-workers about these new Test Driven Development practices. Every day it was “Test Driven” this and “unit test” that. His coworkers were beginning to think that he had some sort of strange fetish with the little green bar that continually colored his monitor. He was a smart guy except for the fact that he didn’t know what he was talking about. You see he really didn’t have a strong grasp of how to implement the concepts he was preaching. He only knew that it was a good thing. It sounded good in theory but as he tried it in production it proved very challenging. He also spoke or knew little of the other aspects of what had been promoted around the globe as “Agile Development”. Concepts such as requirements gathering, iterative and incremental feedback to users and stake holders, use cases and user stories were a blurr. All he knew of was the little green bar that made him feel confident as he coded. And so he went on and convinced a few of his fellow developers how good it would be to color sections of their monitor green as well. Thus he became regarded as the resident expert on TDD and agile practices. Over time he learned more about TDD and started to actually depend on it rather than talk about the relevance of it. He faced challenges each day and over came many with humble successes.

As recent as two days ago he was presented with his latest challenge and revelation in Agile practices, paired programming. A domain expert developer had been paired with our hero, exposing his ignorance to potential danger like a rear view mirror would expose child chasing a ball. Cliff, as he had been called since birth, knew of many common programming pracitces (dependecy injection, intentional programming, refactoring short cuts) but had little knowledge of the domain concepts lock away in obscure table names and column relationships. Neither had he pair programmed with another developer before. It was a very awkward arrangement as the paired developer had the personality of an introvert. He himself was rather shy but did his best to break the ice in difficult situations. She (the other person in the story silly! Cliff did not get a sex change between sentences!) was highly knowledgeable in domain concepts and knew the application they worked on like L.L. Cool J knew his metaphors, like G.W. knows oil reserves, like Pooh bear knows honey. However, she wasn’t as experienced with the fancier programming techniques that Cliff normally practiced. She was more of a get it done developer who could wing an if/elseif combo to make your head spin. Together their combined knowledge was a force to be reckoned with. The exercise in pair programming was a necessary one. Something the Cliff needed for a while but he was nervous as he felt unprepared for the challenge. What if he didn’t know where to start? What if he got into a corner and didn’t know how to continue?

There is one major benefit to working with someone of little words, time. Time to gather your thoughts. Time to think about and plan out the next step. When you work with someone who has a lot to say there is a natural compulsion to have quick answers, to show you’re not stoopid. There the urge to back down when your ideas are challenged. You don’t get that with people who are mostly quite and to themselves. Cliff soon discovered this of his new programming partner and had fun accomplishing things he didn’t think he had the courage to accomplish. He learned more of the business concepts than ever before as his partner was a library of information.

After two days effort they had come up with a business object that emulated existing logic and supported two or three ideas from the original code. That left about two or three… hundred more to implement. It felt like slow progress. It looked like slow progress. An occasional passerby boss would probably even comment something like, “hey, why are you two progressing so dang slow!” Little did they know they were moving at warp speed. Two or three solid ideas had been discovered, nailed down, and modeled in reusable code that was not tied to an entity bean or a JDBC connection. Those two or three ideas were free from the woes of the “build system”, the appserver, and the Spring beans configuration. Those two or three ideas did not know or even care about IBM or Oracle. The only thing those two or three ideas cared about was their job. They were free to do their job in what ever enviornment the developers cared to place them in. It was a refreshing feeling for Cliff as he assured his partner they were heading in the right direction. Along the way she had noticed a few of the three dozen short cuts and IDE tricks of the trade Cliff whizzed by her eyes. As she asked occasional questions Cliff sensed a genuwine interest in better development techniques. It felt as if the two developers were feeding off of each others expertise. That was a good thing.

That concludes our tale today. The lesson is as follows: If you fall in either of the two roles portrayed in our story (most developers will fit either one or the other) find another developer in the opposite role and pair up.

One thought on “Adventures in Agile Development – Paired Programming

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s