I am Not a Robot
Admittedly, I am new to the whole Agile thing. If you’ve been indoctrinated already, please feel free to poke holes in the following commentary.
Recently, a place I have been working at has decided to add some Agile elements to the team’s development process. As they are currently a Big Design Up Front shop, this may not be such a bad thing if the culture can handle the shock.
The first thing to be introduced was unit tests. I was skeptical at first; it seemed like a trendy name applied to something really time consuming. Who has time to write test cases for every single function? After some explaining (”they aren’t meant to speed up the first version, they are meant to speed up all the later ones!”) this started to make sense to me; with teams working on projects, stuff always falls through the cracks. Having a suite that needs to run guarantees that what worked yesterday still works today. Agile++.
Then came pair programming.
There is an uncomfortable subtext to the Agile debate. It is usually positioned as developer-friendly, letting us work faster without having to endure endless management meetings and design discussions. It’s not what is; it’s new. It’s agile! Developers all go through the same things in when working in dysfunctional environments, so when they are presented with a competing model they read into it what they want to see.
From the management perspective, however, Agile is sold as a way to make developers interchangeable. That is the holy grail of IT management for big organizations: How to achieve consistent, good (if not great) results independent of the talent of the underlying team. This is where pair programming seems to fit in. By having every piece of code gone over by two pairs of eyes, you get two benefits:
- All the mistakes Programmer 1 may have made can be picked up on Programmer 2.
- If Programmer 1 quits to go work for another company, Programmer 2 still knows how the code works.
Now, it is a fact that individual coders have different talents; some are good at one thing, but not as strong at something else. Some are about the same everywhere. Some are rockstars. And some are morons and couldn’t tie their shoes without looking it up first on ExpertsExchange. Large organizations (the types that have things like “methodologies”) tend to attract few rockstars and lots of mixed talents and assorted riffraff. (I’m not pointing fingers, I’ve worked there too!) Pair programming works well there because it leaves no individual responsible for the output of the team.
Talented people chafe at having to justify every thing they do to another person. Programmers rely on a lot of intuition and experience, and needing to put that into words for people who don’t “get it” is extremely tiring. Imagine asking Frank Lloyd Wright why he decided to place a roof there, or what the deal was with the waterfall on the Kauffman residence. That would be crazy. He created beautiful spaces that people could understand, without them needing to think about why they were beautiful.
Good code is the same way.
Of course, many coders tend to think that their code and system designs are good regardless of the objective truth, and herein lies the problem. Hiring great programmers is really freaking hard because you can’t distill their greatness through tests or interviews; the hiring manager needs to know the domain and have good taste themselves.
Anyway, I think pair programming is going to take a lot of work for me to digest, if for no other reason than it seems to promote mediocrity. The shear energy needed to convince a whole team of people on how to design a simple login function (for instance) seems to fly in the face of what Agile is purported to fix: Overburdened design discussions. The result is that the easiest-to-understand system will win out, or the one with the loudest supporter. Not the one that is forward-thinking or elegantly simple. Those require the ability to think.
Til next time.
Posted: January 3rd, 2007 under Technology.
Comments: 14
Comments
Comment from Flinky Wisty Pomm
Time: January 3, 2007, 5:39 am
I think you might not be grokking pair programming in the same way you didn’t immediately grok unit tests.
How many times have you been sat working on something, when somebody else comes over to see how you’re doing? You sit talking for a moment, showing them the problem you’re working on and, all of a sudden, things click into place because you’re actively discussing them.
Nobody needed to question you, or have a huge design discussion, but by talking through your work, you saw it in a different way, saw the flaws, saw the best way to tidy things up.
That’s the advantage of pair programming: you’ve always got that other person to keep an eye on you, to tell you to take a break, to ask the awkward questions re: edge cases, to ask “What are we trying to achieve here, and why?”.
I don’t chafe at this, I actively encourage it - programming is hard, and human brains are designed for working out whether the ape in the next tree has got more bananas than you.
In any case, in a decent agile methodology, you shouldn’t be having many big design discussions at all. Write the tests, write the code, clean up the mess. Elegance tends to find its own way out of the refactorings. Don’t ask me how, all I know is that my designs are far more elegant, and far more flexible when I test first than they are when I design up front.
Comment from mike
Time: January 3, 2007, 9:25 am
Flinky:
I have certainly had that “moment of clarity” as you describe it, when talking to someone else has made me see things differently. It only really occurs when I am stuck, however, which is rare.
It is a matter of degrees. I have heard people talk about Agile as a methodology of disciple, where you need to follow the rules all the time to get a benefit from it. Unit test everything, do all coding with others, that sort of thing. The way you describe it seems a little less intense, where you can just ask for help when needed. I wouldn’t mind that so much. It’s just the thought of having someone sitting next to me analyzing my code as I write it sounds incredibly wasteful and annoying, and will result in opinions being shared that are totally inconsequential to task at hand.
-Mike
Comment from john
Time: January 3, 2007, 10:39 am
Here’s what you say about Frank Lloyd Wright and architecture:
–
Talented people chafe at having to justify every thing they do to another person. Programmers rely on a lot of intuition and experience, and needing to put that into words for people who don’t “get it” is extremely tiring. Imagine asking Frank Lloyd Wright why he decided to place a roof there, or what the deal was with the waterfall on the Kauffman residence. That would be crazy. He created beautiful spaces that people could understand, without them needing to think about why they were beautiful.
Good code is the same way.
–
Guess what? Frank Lloyd Wright was a cherished mentor and teacher to several generations of architects. Indeed, much of his teaching was in the mode of “pair programming” as he had students live with him and get a sense for his kind of beauty and symmetry by experiencing the built world as he did.
Many talented people love teaching people — the right people. In a great agile environment, programmers who have been on the team participate in bringing new developers in, and they will want to involve newbies who are interested in the work of the team and interested in learning in an agile fashion.
Teaching and mentoring probably came very easily to FLW because his own father was a music teacher and minister. To be sure, FLW was an idiosyncratic and sometimes oddball teacher: But then so are the great programmers!
Also, if you believe that FLW created buildings for people “without them needing to think about why they were beautiful,” then you have an incredibly impoverished view of why creative people do anything.
It is not unusual for people making an argument to borrow anecdotes from other disciplines, but architecture isn’t going to cut it.
Pingback from pliantalliance.org » I, Not Robot
Time: January 3, 2007, 11:56 am
[…] Mike has an interesting post about some of his recent experience at a company adopting agile. He seems to have a reasonable amount of skepticism but is willing to try things out, which is good. […]
Comment from keith ray
Time: January 3, 2007, 12:26 pm
re “having someone sitting next to me analyzing my code as I write it sounds incredibly wasteful and annoying”
It’s even worse if the feedback comes AFTER you’ve written the code, and mistakes have to be corrected and re-reviewed. That’s why I prefer pair-programming over code-reviews.
However, pair programming is about collaboration, so it’s NOT going to be one hour of someone watching you type. It’s going to be a few minutes of you typing, and a few minutes of your partner typing, and some talking, and maybe drawing a diagram, and so on.
Sometimes you can play “ping-pong programming” where you write a test, and the other guy writes code to pass that test, and then he writes a test, and you write code to pass that test. (That’s Test-Driven Development in a nutshell. Much more fun and effective than writing unit tests after the code was written.)
Comment from Mike
Time: January 3, 2007, 1:58 pm
John:
Thanks for the insight about FLW. I don’t really think it invalidates my point, however. The mentor relationship is much different than the peer relationship, unless you are telling me that FLW took architecture commissions and then had his students design parts while he designed parts. I believe someone of his vision would control very carefully what bore his name, but I could be wrong.
The point about the “not needing to think” was that great artists are able to create beautiful things with impact without needing to explain what makes them that way. The “you know it when you see it” phenomenon. FLW was certainly in that group.
Keith:
You’re assuming I make mistakes. :)
Your approach sounds good, I will have to bring that up as the meetings progress.
Comment from James
Time: January 3, 2007, 3:07 pm
For me whether or not to pair program comes down to the complexity of the problem, talent, experience and the personalities involved.
Like most things in life (and especially in development) to prescribe it wholesale is as ridiculous as to ban it outright.
Pair programming is a tool like everything else and should be used where appropriate. Of course as with all tools the trick is knowing when to use it. Its going to differ depending on the problem to be solved and the team involved (both skill levels and personalities).
Comment from AnonC
Time: January 4, 2007, 10:02 pm
I’ve never done pair programming. But, it seems like it’s something that might help me stay focused. That would be a huge win for me (I hate spending half my working hours daydreaming) and probably a win for my employer too. Getting paired with a dolt would suck, yes, but getting paired with someone that you “clicked” with would be awesome. I’d like to give PP a chance sometime.
Pingback from The Agile Path: Agile as a Journey (Part 2 of 2) « Mark Gilbert’s Blog
Time: August 30, 2007, 8:59 pm
[…] I read a blog posting by Mike Arace recently (”I Am not a Robot”, from http://mikeomatic.net/?p=133) that described some problems he encountered when pair programming was introduced at his place of employment. If you take away only one thing from his post, it should be the point that an organization’s culture can make or break any initiative, whether it’s trying to introduce pair programming, trying to get the team to shift from one source control system to another, or trying to change the brand of caffeine to stock. If the people on the ground aren’t interested in trying X, there’s nothing you can do to make it work. […]
Comment from Blogia
Time: January 17, 2009, 7:14 pm
SOS! My auto was broken on ave. Must I call to service or police?
Comment from Quad
Time: January 18, 2009, 4:59 pm
wonderful post))
Comment from Ksana
Time: January 19, 2009, 6:57 pm
Good nighht, bloggers =
Comment from Pink
Time: January 22, 2009, 10:12 am
what a nice story..
Comment from Trener
Time: September 24, 2009, 6:44 pm
Скажите почему вся страница не грузится через мозилу у меня?
Write a comment