Poop: The Refactoring Method

I developed an quirky technique for dealing with the intermediate states of a refactoring. I call it the "poop" method (no biological metaphor implied). This method is far less controversial than one might suspect, but it is mildly unsettling.

I find myself working in a legacy code base. Refactoring requires me to take several small steps, each of which leaves a sub-optimal intermediate state. I decide to mark the code with some kind of comment that will indicate that the work there is incomplete.

It needs to be a word that doesn't normally appear in code, and which is clearly and obviously undesirable. If I put TODO, it will either get lost in the other TODOs left by well-intentioned people, or else will be stopped by a lint tool that takes such things seriously. Most obscenities would also be a little too likely to be duplicated by someone having a bad day.

My marker comment should not be something so obscene that it will offend or embarrass myself or my reviewers. Something common in baby-talk and yet biologically insensitive will work. I add a comment that says merely "poop." The fact of the comment being in my code creates a mild sense of uneasiness. After all, I don't want my colleagues finding it in production code.

As I finish my refactoring, I do a global search. Sure enough, the word only appears where I've written it in as a marker. As long as I clean up the code and remove the markers, nobody will find a "poop" in my code.

Actually, once my friend George and I left a "poop" in our code. Our coworkers found it. It was easy to tell we'd been caught because the pair looking at the code were laughing and asking why it would say that. It was a little reminder that all was not complete and tidy in our little world. We immediately fixed the code and removed the comment.


I have also used this as an indicator that I need to rename a method. 

If I don't know what to call a method or test initially, the word 'poop' reminds me that I need to revisit that code and determine why it is hard to name. 

Usually poor naming is a sign of poor design; well-designed components seem to practically name themselves.

Maybe you object to the word, but that's okay. The value of the poop method is ensuring you will be uneasy in the presence of unfinished work. Come up with your own variation (be nice) and see how it changes your work habits.

Note: in 2015, Arlo Belshee covered some similar ideas in his article about the process of naming, specifically in moving from missing to nonsense. 

Agile2011 Day 4

This was a wonderful, long, crazy day.

I woke up with a meditation on my mind. I was feeling calm, happy, centered. Morning routine was a breeze, and the walking route to the conference hotel is much more comfortable than the old one.

I spent a lot of time in coaches' corner again. I met some really nice people and had some great talks. I learned the "S.C.A.R.F." acronym and how to use it. I saw old friends. I met new friends.

The Grand American hotel is a wonderful conference hotel. It is comfortable, attractive, and divides into smaller areas nicely. The staff are ninjas, keeping the place clean and preparing for all the events and reconfigurations quickly and quietly. In fact, if you turn your back on your soda, it may totally disappear. James Grenning gave me a glass emblazoned with his book cover, and I had to guard it carefully lest it be swept away by cleaning ninjas. They are so quiet, polite, and efficient that one can never be annoyed with them. They are all superheroes.

I saw the few remaining Agile In A Flash cards (all sold out by end of day) and the three signed copies in the auction (also gone now). This has been a good week for us as authors, and there are new connections and new initiatives that have opened up to us because of Agile In A flash. It is all the more satisfying because the idea was so unusual and only Pragmatic Programmers understood what we were up to. I had a good time talking with other authors, coaches, consultants. I fear to list them all, because I will not remember all of them, but will mention that I really enjoyed chatting with Diana Larsen who I just met. She's invited me to a greater participation in some work at the Agile Alliance fringe and with other professional coaches like myself (perhaps better).

I was sad to see that my Industrial Logic colleague, Bill Wake, was scheduled give a talk on breaking down stories at 3:30, the same time as my Agile Apologetic talk. Then I found that my coauthor, Jeff Langr was scheduled to give his talk about whether to buy agile tools at the same time. My talk was small but we were engaged and attendees seemed to have a good time. Jeff's and Bill's were better attended, and I hear they were quite good. I suspect my lightning talk on Tuesday will the be one most likely remembered.

When I was done in Coaches' Corner I made it outside to see the freerunners, and was in a cloud of people (new friends and old) which was swept into the grand ballroom. Matt Barcomb and I appropriated an empty table, which soon became the "cool table" as we crunched together to allow more people to join. Lean Dog brethren joined us and entertained us. We watched a trampoline team do arial skiing and arial gymnastics and arial snowboarding. They were amazing olympic athletes, and one was even a contestant in American Ninja Warrior (obstacle course game show). The final scheduled entertainment was a band playing classics old and new, but they were sadly plagued with sound problems.

Following the scheduled entertainment I was invited to a room party which included many recognized great people of the Agile community and many sharp newcomers. Bonnie introduced us to fire spinning via two led-light green balls on chains, which stood in the place of actual fire. We took turns being schooled in elementary moves and it was a good time. I also had time to argue with Bryan Beachum. I talked with Diana and George and Jeff about the possibilities of helping to create cirriculum, and talked over general coaching stuff with James Shore. It was a really great time, but lasted longer into the evening/morning than I'm accustomed.

I've new friends and new ideas, and so ended day 4.

Free, Cheap, Scheduled: retrospective technique

I was telling Esther Derby about a little trick I worked out some time ago at one of my clients. The retrospectives had gone stale, with team members offering the same "we should..." list iteration after iteration.  I suspected that they didn't feel that they really had the authority or permission to change their process for the better.

I had a good relationship with the CIO and wandered into his office.

I said, "we have some changes we want to make, and they won't really cost any money or affect other departments, and I just wondered if you think it would be okay to do them."  The CIO looked at me incredulously, "Of course. That's a silly question to ask."

"Alright, then there is this other change.  It might take a few man days out of each iteration, but it will be helpful for the team.  Would that be okay?"  He sighed, "If it's a few man days per iteration, we can afford that. Go ahead and take that time. You don't need my permission for that."

I paused a few seconds for effect. "We also have recognized some tough changes we need to make.  They might take a few man weeks out of an iteration.  Would those be okay?"

This time I got a few seconds of silence in return. "Tim, we can do that kind of change, but we have to schedule it. We can't put releases at risk, and we have promises to fulfill, so we just need to make sure we do them at the right time.  They need to be worth it, but we can do that."

I thanked the CIO and wandered back to my team in time for the retrospective.  The team identified many of the same problems, and proposed the same solutions they hadn't worked on the last few times. I went up to the flip chart and divided it into three sections called "Free", "Cheap", and "Scheduled." I explained that these categories had been approved by the CIO and we should begin making changes immediately after the retro. I asked them to pick things they really wanted to do.

The team put changes into the correct buckets, and we picked the ones they felt that they had the energy to work on. The scrum master took the task of moving the "scheduled" items into the schedule, the rest we started on immediately.

If your team is having trouble believing that they really have permission to "spend money" making changes to they way they work, maybe you will find this technique useful.

Agile2011 Day 3

I just can't get it in my head this was Wednesday.  I'm very tired.  I'm an introvert, you know, and we draw energy from alone time or time with a small number of close friends.  Being in rooms with hundreds of people most of the time is really work.  On the other hand, I get energy from my work, and spent a lot of time talking about work.

I spent the morning with Michelle from NavTeq, talking about people, processes, transitions, and strategies for making other people more successful. I'd re-met a fellow from NavTeq after my talk on pairing yesterday, so it's cool that I'm seeing so many of my Chicago cousins. I'm hoping to see more of them in the future.

I attended a tool demo later, but I didn't realize it was a testing tool for C#. I thought it was going to be a talk on how to bring testers and coders closer together and blur the lines between them. I left disappointed, but on the way out met a nice fellow who is a new scrum master. We chatted until time for lunch.

Lunch I had with a number of my Deere friends (heh). Deere sent a lot of delegates to this conference, which really speaks to their level of management support. Thanks to the John Deere executives who made it possible for all these good people to come, absorb, learn, and converse with the constellation of Agile dignitaries here. May they pay you back tenfold in fresh learning and new techniques.

After lunch I went to GeePaw Hill's talk on geek leadership. I learned some useful techniques that I will put into practice in the near future. It's good to have smart friends.

Later I ended up mostly hanging out, populating coaches' corner, and eating food. I saw a lot of good people. I met people who have been following my blogs (always a kick for a blogger) and showed off the card deck. I also had some good responses to my talk yesterday "will pair programming ruin my company."

Today there was an announcement that Industrial Logic and Version One have a strategic agreement. Announcements focus on V1 market our eLearning as part of their offerings. I have new brothers.

Tomorrow Jeff Langr and I will be pushing the limits of acceptable behavior in our individual talks. He has a talk on "the only agile tools you really need" (a must-see, controversy-stirring feast of common sense) and I will present "the fundamental agile apologetic."  Actually,  I only hope it will be a fundamental apologetic, but I have decided to allow the talk to go in new directions if need be.  Teaching, learning -- I'll be doing at least one of the two.

It's hard to say what tomorrow will bring, but it should be interesting at least.

Pairing Styles

Overall, pair programming isn't as controversial as you've heard. It depends on your styles of pairing. Some styles of pairing are very common, even among non-agile teams. They tend to be episodic, and last just long enough to get or give some aid. The good news is that they work. If a team views pairing with trepidation, these are common, non-threatening forms to start with:

• Rescue Pairing
• Training Pairing
• Brainstorming
• Experimenter/Researcher

Others are such bad ideas that they are rightfully avoided by all sane teams I've seen so far.  If you are considering pairing, and a team member balks, you should see if their mental model of pairing matches one of these styles. I suspect a team should decide that these styles will never be practiced personally, or tolerated within the team's pod.  You have my blessings to object to pairing if "pairing" means:

• Worker/Rester
• Worker/Watcher
• Master/Slave
• Bully/Victim
• Writer/Critic
• Ball-and-chain pair marriage

And then there is the form of pairing that matters most.

• Peer pairing

Peer pairing is about two people who know what they are doing, who have skills, who are not stuck or lost or confused, designing and implementing ideas as fast as they can. A peer pair constantly vets ideas, tries alternatives, detects surprising failure modes, revises plans, teaches, learns, experiments, laughs, tests, commiserates, and grows together.  At least for a few great, exciting, exhausting hours.

The problem with peer pairing is that to the observer it might seem like rescue pairing or training. If you are always being trained or always being rescued, then you might seem like you're not much of a programmer.  In this case, seeming is the enemy of being. A team may be so concerned about seeming competent by not pairing that they don't increase their competence by peer pairing.  I suggest that this is a human foible, and we have to recognize.

When we talk about pair programming, we usually intend peer pairing (and the other good types at the top of the list), but people often hear us as meaning one or more of the bad types in the middle.

I hope to rephrase the question.  When you tell me you "don't believe in pair programming" then I hope to ask you about the pair programming you object to.  Chances are I will feel the same way, and with that out of the way we can talk about the kinds of pairings we might actually try.

Agile2011 Day 2

A lot of today was spent in the Coaches' Corner, where several more convention-goers were served with expert advice.

I spent a chunk of my "alone time" today working on my "Agile Fundamental Apologetic" talk for Thursday (Fringe stage).  I hope to establish that if we weren't doing agile, we would have to do something very like it. I even got to pair on some of the slides, which was a great time.

Jeff was finalizing his Test Abstraction talk (based on our Agile In A Flash card), in which he showed some poorly-composed Fitnesse tests, and some much more well-composed, abstract versions of the same test. It was practical and useful. I think he opened testers' eyes to new possibilities, and that 7 minutes talk will have reverberations in many places.

After Jeff's talk was my own. Mine was titled "Will Pair Programming Ruin My Company?" in which I answered a few questions I've heard from managers over the years. Given how much controversy and resistance arise over this crucial practice, I think the talk was well-timed. It was also well-received. I had a great room, appreciative and inquisitive and thoughtful.

I also did a very small, personal session on my Agile Coaching Metaprocess.  Actually, it was a conversation with two people, one of which has heard it a million times already.  It wasn't a box office smash, but I've given the same talk with others through the week.

Quite a bit of time was spend in talks about consortiums, guilds, and interest groups. There are many great ideas bubbling under the surface of the Agile Alliance umbrella.  I spent the evening (late into the evening) having supper with an impressive group of agile luminaries. I know I was impressed.  We talked about providing programmers with an agile education.  Of course, as an Industrial Logic member this was of interest, but it has also been a long-term interest of mine as an agile coach. Thanks to Matt Barcomb for putting the evening together.

Agile2011 Day 1

This has been a very good day.  I was able to staff the Coaches' Corner and visit with other coaches when we weren't engaged with convention-goers.  I enjoy the interaction, though I'm admittedly an introvert.

Jeff Langr is here, and we were able to talk about many things and even promote the Agile In A Flash deck.  Three copies went to the live aid silent auction.

I was looking dapper in my blue Industrial Logic shirt and sharing the Agile love and coaching philosophy with people who were interested. We talked about measurement, e-learning, and raising self-coaching teams. We talked about business and busyness and listened to many stories.  I was also given a Lean Dog fuzzy hat, which I sometimes wore when I wasn't feeling to warm or was unconcerned about creating mental ambiguity about my situation.

This place is a who's who of object mentor alumni. All my old friends have new gigs and new ideas and it's wonderful to see them all.

The ice breaker is over, and I'm about to wander off to join some friends, but I wanted to mention to any attendees that I'm speaking tomorrow, a lightning talk on "will pair programming ruin my company." Teaser: it just might.

Good night to all.

Leadership

I'm doing some reading and some experiencing, keeping my eyes open for the concept of leadership.

One can see leadership as a combination of visibility and confidence. This seems to work out pretty well, as an observation in arrears. Leaders who are successful often have high visibility and make decisions with a high confidence that things will work out well.

When leadership works, I see it as the leader understanding the team and promoting the team by  improving the teams alignment with the hierarchy of the company and its customers, making use of the team's strengths, and helping . Such a path seems to grow confidence, and the success gives visibility to the team and its leaders. This is the slow, steady path.

I see some leaders succeed by other means, some seeming rather virtuous and others less so. I'm particularly critical of those who see leadership as wresting authority from others though political games and social manipulation. Such leaders may actually inspire confidence, since the leader is seen as growing in influence and respect. It may bring such a leader up the hierarchy quickly, but will also tend to give the leader a shaky support base. For such a person, support is something comes from the hierarchy and the role of follower must be inflicted on competitors. It is a quick path, but the innate self-centeredness competitiveness may result in a very unpopular position and many enemies.

A juvenile view of leadership is that it is about being seen and telling others what to do; a starring role with the hierarchy and team as supporting cast. This seldom translates into the kind of leadership any organization really needs, but is quite reasonable. After all, a leader is visible and has authority.

I'm leaning toward the idea that he leader I want to be is the guy who prepares the way for the team, aligns them with the hierarchy and customers, and looks for ways to help them achieve their goals more fluently.

I'm still most motivated by our B.E.S.T. leadership card. I find it sums up all the best leaders I've known.