XP to the Extreme – Literally

A team in which I was a member transitioned from Scrum to XP (Extreme Programming).  XP was a new concept to many, and there was some learning that had to occur.  The true definition of what each principle, value, and practice meant to convey was muddied then realized.  Some aspects of XP, we took it literally…to the extreme.  Two of the principles that I'd like to address are "Simple Design" and "Pair Programming."

Simple Design

This is a concept in most agile frameworks, but XP put a little more emphasis in not over-engineering or building more than the minimum.  Now, that last phrase can be quite misconstrued.  Not over-engineering and doing the “bare minimum” (there’s an Office Space reference for you) is vague.  What is the minimum to complete a story?  It works?  It’s tested?  When all the acceptance criteria is met?  My team had an extreme and literal interpretation to that.  We answered the three questions above, and that’s it.  Thus, when it work, it was tested, and the A/C was met, then it was done. 

We had lots and lots of small stories.  Things were getting done.  Pairing partners were switched every day or so, and work streams were flowing along for various aspects of the application. 

Eventually, we realized there were several places in the project were code was duplicated, and coding patterns for aspects of our application were done several different ways.  As we realized these shortcomings and wanted “cleaner” code, we wrote more small stories to refactor them later.   These stories got pushed down in the backlog with the reasoning that once we were feature-complete, we could go back and make things ‘nicer’.

Well, the code became harder and harder to work inside.  A “simple” change sometimes cascaded many days of changes because of the spaghetti code. We had a project with many, many little completed features that were siloed from each other.  This forced workarounds, integrations, and hackery to get things to work properly.  Still, the refactoring stories (as we called them) were pushed off until later.  I mean, we were using XP, and XP is supposed to help you make quick code while being light and agile.

We eventually reached a breaking point.  We pulled “that one story”.  The story that broke the camel’s back.  There was no ignoring the mess. There were no more excuses.

Some blamed XP, and that it didn’t work.  Some blamed other developers.  Some blamed the programming language.  What was the real cause that brought us to this point?

There’s some enlightenment I find in Ron Jeffries’ post on XP, and his comments on Simple Design (https://ronjeffries.com/xprog/what-is-extreme-programming/#simple).   A key statement is what we were avoiding, ignoring, or ignorant of: “teams engage in quick design sessions and design revisions through refactoring, through the course of the entire project.” 

Design sessions weren’t happening.  Pairs pulled stories and those two just figured it out.  Also, they never shared with others what they had done. 

Another thing that was not happening was refactoring.  Refactoring was deemed as “not bringing any value to the business.” The “bare minimum” was to not refactor if it works, is tested, and meets the acceptance criteria.

Some key practices that should not be skipped in development:

-       Design sessions with the team

-       Refactoring

-       Sharing with the whole team what you’ve done

Design Sessions

I am fully confident in my teammates.  But, I know and they know that not any one of us has the perfect code, design, or answer themselves.  Nor does a given pair have perfection, either.  It is only when the whole team discusses, contributes, and challenges will a better design emerge. 

I encourage all teams to incorporate design in their IPM’s.  XP doesn’t exclude design.  It’s supposed to enhance it.  It’s not supposed to silo teams, but bring them together in collective ownership.

Outside of XP in one of my Kanban teams, we had a column name “Design Review” that was before “In Progress.”  This served as a gate to review with the team how you planned to tackle your story.  Sometimes, others would say things like, “Oh, did you know library X does that for you already?” or “That sounds great, but did you know that…”, etc.  We need to find that gate in XP as well. 

Refactoring

Oh, so important!  We all knew it was best practice to refactor at the moment when you are closest to the code. And if you see code duplication, refactor.  Make it DRY.  Make it simple.  Establishing patterns and conventions is good for the agility of your codebase.  Yes, we want to keep it simple to avoid overengineering or making that uber-library that only gets used once.  However, avoiding refactoring will cause your development to slow down and is an anti-pattern to good agile development.

Sharing with the whole team

One of the advantages to pair programming is to share knowledge and prevent silo’s.  I don’t think it’s enough or adequate to only share by pairing.  There are times when you and your partner do some highly complex things in your day.  Leaving that knowledge with just you and your partner leaves the rest of the team in the dark.  Even if you switch partners on the same code-base or feature, one partner can be well behind the other.

Even though it is not a prescription of XP, I fully support code reviews, especially after something that required some deep thinking or design.  You don’t have to call it a code review.  Call it a “team acceleration circle” or a “knowledge transfer session.”  It doesn’t matter.  The important thing is that the knowledge is shared.  Also, no matter how brilliant you are, you and your partner can get tunnel vision.  Others on the team can challenge your thoughts which can prompt better design.

Pair Programming

Pair programming is a hard pill to swallow for some.  When I first heard the concept, I shuttered and it made me sick just thinking about it.  However, I have done it for many years now, and I see the great benefits in it.

Pair programming can be toxic to a developer as well.  Coming out of XP training, we took it literally…to the extreme.  The decree was that no code was to be written without pairing, and you had to pair all day long.

The day started with a standup.  Immediately after standup, it was strait to the shared machine with your partner, and you started coding.  Twelve O’Clock, stop everything…it’s lunch time!  See you in one hour, exactly.  This afternoon, we work until closing time.  Come back tomorrow to do it again!

It was much like working in a factory. It felt like slave driving.  It felt like, “Can I go to the bathroom, now?”  It felt like I was no longer an individual.  My talents, my skills, my personal space…wasted or violated.  

What was going on?  I had been doing pair programming for years.  Many times, all day and every day for months.  I didn’t have a problem before.  I actually had enjoyed it in the past.  Why was I hating my job, now?

First, it was my loss of personal space.  I no longer had my own cubicle to retreat if I wanted to get away or put my personal belongings.  I no longer had my own machine. I was made into an “equal”, and I no longer was able to stretch my wings or slow down if I needed to. I had to stay at my partner’s pace.  I no longer felt that I could do what I wanted to do when I wanted to do it.  That leads into my next contention: the clockwork aspect.

The day was so much like a factory clockwork schedule that I no longer felt like a professional.  I felt like an hourly worker at a fast food restaurant. The feeling among all of us was that we were absolutely dependent on a partner to write code with no exception.  If your partner stood up to use the restroom or take a phone call, you had to stop coding too!  If your partner had a meeting, you either had to go with them or find another pair to “thruple” (A thruple is three people programming at the same time.  As a side note I think it’s a waste of resources most of the time.).  There was no taking lunch early.  You felt hungry, but guilty.  If you wanted to go eat, that meant disrupting your partners ability to work.  You held your bladder as to not disrupt your partner’s train of thought.

Pivotal was quoted quite a bit.  “That’s what Pivotal does.”  Quite honestly, I would never work at Pivotal, especially if that’s how life is. However, I think we’ve misconstrued “what Pivotal does.” 

Needless to say, there were mutterings of wanting to quit, or move to other teams.  Moral was low.

Pair programming isn’t a punishment.  It shouldn’t prevent you from being you, or stifle your ability to shine.  It’s meant to empower teams and individuals to get rid of some failings when you are not pair programming.  These are some of the advantages of pair programming:

-       Knowledge sharing

-       Better design

-       Checking for mistakes

-       Better code patterns

-       Coaching

-       And more…

We are all human.  We have our needs and desires.  We have our mental gifts and limitations.  Here are some things you can do to mitigate or eliminate the angst of pair programming:

-       Not every line of code needs to be observed and critiqued by a partner at the moment it was created

-       Communicate your needs with your partner and adjust

-       Separate sometimes

Not every line of code needs to be paired

So, if your partner walks away to use the restroom, how much damage can you really do in that short time?  How about an hour-long meeting?  A full morning or afternoon?  There is a threshold in which you have written so much code without a partner that it can be harmful to your pace.  For example, you can make some poor decisions and have to unwind many lines of code to start over after your partner finds a flaw in your logic. 

However, in short intervals where your partner is gone, it’s quite easy to do a quick review of what you’ve done to let your partner catch up and ask questions.  When they get back, you could let them drive so they can wrap their head around it.  My threshold is about 2-4 hours, depending on how rapidly I can crack out code for a particular feature.  After that, you’re bleeding into a zone where your removing the advantages of pair programming.

Communicate your needs

There are several ways you can communicate with your partner about your needs.  You can start the day by saying, “Hey, I need to run some errands.  Mind if we do lunch at 11:00 today?” It can also be organic and dynamic though the day, “Dude, I’m really hungry.  Alright if I step off to lunch, now?”  A good partner will have a dialog with them, like “Sure.  I think this is a good stopping point.” Or “Can you hang on for about 15 minutes while you help me think through this part?”

Your partner is a human, just like you.  When you start pairing, you need to be partners. Being partners means bringing lots of respect and courage.  Hey, wait a minute…respect, courage, and communication are all XP values.  Did we forget all those while trying to comply to principles?  Values are an integral part of XP.

Separate Sometimes

On occasion, your brain works best away from someone else…and away from how they think, their tics and idiosyncrasies, their talking, etc.  There have been times that if I just walk away and isolate myself for a short bit, the solution presents itself.  Another example is when I jump on some code with a new partner where he has worked on it the last two days. I might need some time to absorb the code and wrap my head around it.  Maybe I need to go learn a new concept or read-up on some technology.  Maybe, it’s all new to all of us and we are doing a spike or research.  A good book works great for me, where my partner wants to watch a video.  Have you ever tried to read a web site while your partner is driving?  Most likely, you need the scrolling to go faster or slower.  And if they are jumping all over the page, it’s useless to try to keep up.  That’s because they are going the pace their brain is going, not yours.

It is absolutely acceptable to separate from your partner for some established time, then come back together to get the job done. The key is in communication when you do separate.  However, it is not acceptable to go away and do separate things for the whole day because “you don’t think like your partner.”  The idea of some short, establish separation is to allow both of your brains to get where they need to be so that you can get the code written together.  A little bit of separation is healthy.  If you don’t, you’ll likely have one person writing the code, and the other person zoning out all day wishing it was quitting time.

Conclusion

In any agile framework, whether it’s XP or the next thing invented in 5 years, it’s meant to help you get your job done well and quickly.  You should take aspects literally at start.  However, don’t be afraid to adjust if it feels completely wrong or it’s causing you to slow down.  Use your retros to truly evaluate your thoughts on the framework and your performance within the framework.  Seek guidance from the experts, even if you already asked before.  Seek clarification.  In the end, we all want to deliver value to our customers quickly while smiling about it while we are doing it.  If the code you are developing grows to feel like working in mud or quicksand, something is not right.  If you feel like you want to quit the job, something is not right.