Category: blog

612 Software Foundry

After nearly two years of working under the name J. Pederson Consulting, Inc., we have decided to do business as 612 Software Foundry as it more accurately represents what this company is about and reflects what we offer in terms of software delivery and consulting services. Over the next few weeks, you will see changes to this site to reflect this.

Where can you find us?

612 Software Foundry can be found:

On Pair Programming: Excuses – Part 2

Last Saturday I attended Minnebar, a local (un)conference here in the Twin Cities that attracts somewhere towards 1000 of the area’s best tech, design, and entrepreneurial talent. In the last session of the day, there was some side talk about team best practices and one mentioned was pair programming. At the end of the session, someone asked “How do I convince my manager that pair programming is worth it? He says he doesn’t want to pay two people to do one person’s work”. Yes, that is a real excuse. I’ve heard it before myself. Few of the answers offered were very serious or if they were, they were not practical. Normally I cannot simply fire my manager and get a new one. Instead, with a little education, some coaching, and challenging the leadership/management team to take a risk, you can see where pair programming will take you, your team, and your product. And maybe, just maybe, it won’t work out. It’s not for everyone nor every project, but without giving it a shot, you will never learn if it will work or not.

While Part 1 focused on programmer excuses, this will focus on excuses made outside of the programmer role, from the business perspective.

So let’s review.

What is Pair Programming?

Pair programming is a software development practice where two programmers sit at the same computer and solve the same problem together, as a team. Remember that this problem the team is solving, whether it be a bug, new feature, or configuring a server, is a team problem. In the most effective form of pair programming, each member of the pair is doing something different and complimentary to the other person. One is thinking at a code or unit level and is doing the typing. The other is thinking more abstractly and strategically, both for the problem at hand and how it fits into the system and product as a whole. These roles will switch frequently, and with a well-matched pair, it happens naturally.

Pair programming is akin to having a co-pilot while flying. Each member of the pair acts as the other’s conscience and challenges the other to think more about why and how to solve a problem. They are forced to explain what they are doing and why, all at the same time they are doing it. It takes practice. As the pair encounters problems, they brainstorm ways to solve them together. They decide together to spend an extra hour refactoring something.

So what are the excuses?

It’s Too Hard to Start Mid-Project

Let’s face it. Delivering software is hard. Many projects run late or over budget right from the start. It can be terrifying to start a new practice mid-project when it has the potential to disrupt the timeline or budget. Potential. But what if by practicing pair programming, you reveal a new challenge you hadn’t anticipated? A critical architectural flaw. An inaccurate business assumption or requirement. Would you rather know that challenge mid-project so you can proactively manage it or would you rather learn about it from your users after the project has launched?

Only Half As Much Work Will Get Done

There is this assumption that removing a computer from two people will reduce the amount of typing that happens. We are not typists. Believe it or not, the majority of our work is not dedicated to banging away at the computer. Our work takes thought, brainstorming, and collaboration. And by definition, collaboration requires… talking and working together.

We can also use the doctor/server metaphor here. Pairing is going to help you move into more of a doctor role, where you are asking more questions about why you are solving a problem a certain way or if you are even solving the right problem. Sometimes the right thing to build may not be written down in the acceptance criteria of the story. Building the right thing might actually involve talking about it.

But let’s be honest. There is typically a short term productivity loss, but costs do not double with pair programming. Some research here and here has reported that only about 15% more time is spent. However, this cost is recovered with increase in quality, spread of knowledge, and increased truck number. I’m not going to go over the math here, but those references lay it out pretty nicely for you.

Why Would I Hire Two People To Do the Work Of One

First of all, why is this project one person’s job? Isn’t the success of the project based on what the team accomplishes as a whole?

Second, see the section above.

Nobody Is Working. It’s a Social Hour Around Here!

Are you sure it’s a social hour? Listen carefully. Is the pair discussing which map implementation would best fit this problem or are they really talking about the latest gossip? Pair programming is actually going to create less disruptions. When a pair is deep in a discussion about a problem, there are less likely to be drive-bys because people don’t want to interrupt. The pair is focused. People are also less likely to succumb to distractions such as emails, meetings, surfing the web, facebooking, and tweeting because there is an element of peer pressure.

As for talking about the latest gossip, keep in mind that this is a way of pair bonding. As a pair gets to know one another, they begin to trust each other. And if they trust each other, they are going to start taking the kind of risks that you want them to take. The kind that will elevate your team, product, and company to new levels.

What are your thoughts?

As I continue to practice pair programming and have conversations with friends and colleagues about this topic, my opinions are ever-evolving. So keep in mind this is a work in progress and your opinions and experiences are very welcome in the comments.

On Pair Programming: Excuses – Part 1

You definitely should not try pair programming. It’s too hard and there is no way putting two people on the same task is more productive or effective than having everyone work on their own task. Having all of our project tasks in progress means we are getting tons done, right?

Not necessarily. I’ve been pair programming pretty regularly for a little over a year now on a number of different projects and there are definitely a lot of excuses made as to why pair programming does not work. Here is Part 1 of what I’ve heard or read about, and what was contributed from the audience during my talk at Agile Day 2012, along with a few arguments or solutions. Part 1 will be more focused on programmer excuses. Part 2, to follow, will be focused on excuses made outside of the programmer role, from the business perspective.

Programmers are Introverts

Yep, many of us are, myself included. It can make me nervous. With pair programming you build a relationship with your pair partner. You gain each other’s trust. Pair programming is a social skill that needs to be learned. It gets better as you become more comfortable pairing and get to know your partner. You build a relationship and gain each other’s trust. You learn to lean on that safety net and you start taking more calculated risks that build quality in and be innovative early on.

I have a personal “bubble” and I don’t want you in it

I suffer from the personal “bubble” myself. I learned early on that if you are set up in a one person cubicle with two people shoved in and one hovering over a shoulder, you are not pairing. It’s also horribly uncomfortable. Set up a pairing station with two chairs, one very large or two decent sized monitors, two keyboards, two mice, all attached to the same computer. At one client, we all were given our own laptops, a keyboard and a mouse, but instead of everyone getting two monitors, there was a large monitor dedicated for each pair. You don’t have to worry about passing the keyboard and mouse back and forth. Just steal it.

You’re going too fast for me to keep up

If your pair partner is going too fast for you to keep up, stop to ask questions. Ask why. Get explanations for certain approaches. Slowing the other person down a little has the added benefits not just of knowledge transfer to you, but also giving you both the opportunity to give a solution some thought. Many times, trying to explain something in words, out loud, you or your pair partner will find something great or not so great about that solution.

You’re going too slow and I’m getting bored

If your pair partner is going too slow for you and you are getting bored, put your teacher/mentor/coach hat on. The pace will increase once the comfort level does. Switch pairs more frequently. And if the comfort level does not improve, it’s possible that this is not a good pairing.

My pair partner is way older/younger than me and our styles/pace/knowledge don’t jive

This is one suggested by the audience at Agile Day 2012 and I thought it was pretty good. There was a decent spread of age in the room, so someone much younger actually spoke up and said that while this can be intimidating it always provides a great learning opportunity. From the other perspective, one way of looking at it would be that it is a mentoring opportunity to share your own knowledge with someone else who doesn’t have the experience you have.

My partner is always multi-tasking on a second computer

Stop. You are not pairing at this point. If someone is multitasking, it’s likely that you both need a break. Or if it’s critical to the task at hand, get both people involved if you are doing a stack overflow search or crafting an email to a client.

My pair is a keyboard hog

A simple and usually effective solution to this one is to use the ping pong pairing approach where one person writes a test, the other implements and then writes the next test and so forth.

My partner is telling me which characters to type!

You aren’t pairing. Find ways to get both of you engaged. Use the ping pong approach. Take a quick break/walk – together or alone – away from the computer. Have open communication. Open your mouth and say something. Have an opinion and voice it. If it is really bad, get up and walk away to make it obvious that there is no pairing happening. If you are being micromanaged, asks for more details beyond what characters to type and reasons why.

My team is distributed and remote pairing is hard

Yep, it is. Don’t do it. But if you must, here are some tools I’ve found useful:

  • gnu screen/vim
  • ichat + IDE + headset
  • Skype (voice only) + screen sharing tool
  • MS Communicator/remote desktop + voice
  • Join.me – voice + screen sharing
  • Invest in a decent set of headphones and a microphone
  • Facetime
  • Google Hangout

My team sets their own hours

Set a common hour or two or three per day/week for pairing. You could also pair people who do have the same schedule.

I’m getting sick of my pair partner

Rotate pairs frequently, but beware of the effect of this, which is known as promiscuous pairing, where team members don’t learn enough about the task to be able to support it in the future because pairs switched too frequently. Use the “pair stair” to ensure everyone is pairing with everyone else evenly. You will quickly notice when two people never pair together.

My current team aims to swap pairs every couple days by swapping in a new person to the story once the most recent person has become comfortable enough to carry the story on. This allows you to keep some continuity as well as still build up some knowledge about an area of the system. So far it is working well for us and solved the problem we were having of never swapping pairs and our strong dislike of switching every single day.

My pair partner smells

Basic hygiene, people! Shower, wear deodorant, and brush your teeth. I have enacted Team Gum, a bucket of gum dedicated to the team for after lunch purposes. Also, keep team lysol wipes and hand sanitizer handy – not for showering but for reducing germs, especially during flu season.

Not convinced pair programming is effective?

Tell me why in the comments. I know that pair programming has it’s place, but I am interested in when you use this practice and when you don’t and why.

How We Got Our Geek On at Agile Day Twin Cities: The App

Friday was a blast. It was the day Agile Day Twin Cities was held. It was the day we got our geek on. In true agile fashion, we spent a four hours iterating on something we, the conference attendees, thought could be very useful. The true measure of it’s usefulness was finding out at the end of the conference that we had real users.

Disclaimer

There are multiple references to the “app” in the story below. While in the end we had a simple HTML page, we went through the typical process that teams go through to figure out what they need and how to build it – including thinking we needed the coolest technology and to build an app-like experience. We ended up with the smallest chunk of work that could possibly satisfy the needs of our users in the timeframe available.

The Story

The conference was held at the Minneapolis Institute of Arts, which was a fantastic venue for a conference. The afternoon was scheduled to be filled with open space sessions where the conference attendees volunteer topics they are interested in talking about either because they know about it or want to learn more about it. Each room reserved for open spaces holds copies of cards of the schedule for the day so attendees have a reference to what’s happening where. Several people, including myself, volunteered to frantically copy these cards by hand as the topics were being proposed and put into time slots. This photo shows the topics and where people will gather to discuss them:

Open Spaces

One room was designated beforehand to “Get Your Geek On”, a place for wandering geeks to gather to build something, practice pair programming, test driven development, or whatever geeky thing they wanted to talk about.

Open Spaces

As we wandered down a long hallway through the length of the museum and three flights of stairs to the Wells Fargo room with our lo-fi schedule for the afternoon, we found out one of the sessions was removed and another was added. Quickly, we updated the cards and continued on our trek.

Fifteen minutes into the first open space session, only the three people volunteering to facilitate the Get Your Geek On session were in the room. Maybe people didn’t know where we were. We realized that at any time, the open spaces schedule could change and we’d never know it. This sparked an idea.

What if we built an open spaces schedule app?!? The conference organizers could load the schedule into the app or update the schedule any time it changed over the course of the day. Conference attendees could reference the real-time schedule on their phone, laptop or tablet. Brilliant!

Iteration 1

The three of us spent about 10 minutes wire framing what we thought would be useful. During that time, we took it a little further than necessary, but quickly realized we didn’t need extra bells and whistles at this time. There was no need to be able to show the entire conference schedule for the first iteration because the conference was more than half over.

Soon, other attendees started randomly filtering in and contributing ideas. One person suggested using jQuery Mobile or Backbone and Twitter/Bootstrap so we could have a more app-like experience. Having just built a couple of those apps, I suggested we take a step back and look at what we really need to deliver for iteration one. We need to be able to display the schedule. That’s it. Nothing more. So instead of breaking out into a JavaScript single-page webapp dance, we took one very nice picture of the entire schedule and posted it on the web. By default, the wordpress theme we were integrating into supported a responsive design and allowed for zooming. Version 1 released!

Working on V1

Iteration 2

We quickly moved on to iteration two. We noticed the one photo was still difficult to read and if there were a schedule change, we’d have to retake that picture and update the whole image. We decided on individual photos for each schedule card. With about five minutes of iteration planning, version 2 was released shortly thereafter. This iteration, we did more of a test driven development approach, with a couple of people reviewing the quality of the images before uploading them to the new site. We also implemented a version control strategy, using GitHub to host the repo so multiple people could work on this. More people had started to filter into the room and we lost a few others to other open space sessions. Having the team work in the same co-located space and a couple people paired up at one laptop throughout the afternoon allowed us to continue the work even when a few people took off for the afternoon.

Iteration 3

Iteration three planning started and someone suggested building an Android app: “Who has the APK on their laptop?!?” Little did he know that 99% of the people in the room were Apple fans and we couldn’t market an Android app to iPhone users. We decided to stick with a webpage. It was then we got wind of other apps out there that might do the job for us. Oops. We forgot to do our research. We took a quick detour to The Google and didn’t come up with anything too relevant but there was still a rumor going around that there is something in alpha. Never found it so we continued on. Version three ended up providing a better user experience where attendees could navigate to the schedule by clicking on the room presented in thumbnail form. Version three released!

Iteration 3

More people had filtered into the room and others had moved on. One conference speaker stopped in and started asking about what we were doing, excitement in his eyes. Soon he said, “Let me see the GitHub repo!” He looked at it, the excitement quickly left and he said “Wait, it’s only an HTML page?!? Why didn’t you think about using Rails to host this? That woulda been so much cooler.” Yep, it would have been cooler, but it would not have met the needs of our users. It was all about the Minimum Viable Product and time to market (the conference ended at 5pm), and we learned that quickly in iteration one. See, we already had those discussions. We made a good decision and maybe a future version will require a framework like Rails.

Remember when I mentioned earlier that the Get Your Geek On room could also be used for talking about the latest geeky thing you wanted? Well, during all of this, a few of us were introduced to a new iOS game, Letterpress. During our “breaks” from the open spaces schedule app, we played a few games, making sure to have a little fun and do some relationship building while we worked. Just before one of the sessions ended, someone (seriously) asked “So, what are the next sessions?” The quick response from the team was “Dude. Checkout the app!”.

Iteration 4

Planning for iteration four started and as it was the last session of the day, a few from the original team returned and helped motivate the team into a fourth release. They came back from the main ballroom where most of the other open space sessions were being held and told us that people were actually using our app! How exciting – we had real users. Apparently our “press release” tweeting was actually doing some good.

The team proposed that for iteration four, we would implement a nice to have, quick feature, to provide directions to the post-conference event.

The Final Product

The Result

The true measure of the usefulness of this app was when I arrived back up stairs for the closing statements and a friend of mine came up to me and said she had been using the app all afternoon because she didn’t want to have to walk back to the schedule every 15 minutes.

So, while we didn’t use the “cool” technology, a framework, traditional story authoring, iteration planning, pair programming, and test driven development processes (who needs xUnit tests when you’re writing HTML?), we used what worked for us and we were able to quickly adjust both our process and our product when something wasn’t working. In the span of about 3 hours, we released four versions of the “app”.

Were you at Agile Day Twin Cities? Did you participate in the Get Your Geek On Exercise?