In any consulting job, a project truly fails when expectations are not clearly communicated. In Ruby, we have a great tool for communicating expectations about code. What if we applied that same tool to real life? The anchors at Pivotal Labs have a wealth of knowledge about what elements contribute to a smooth running project. I have my own ideas about what makes a project fun to work on. Below is a very short start to what I like to see about a project going in. This is not to say that a project that fails this spec is "bad", just that I feel a lot better when a project already has these things in place.
Though I am certain someone could do it, it is hard to dispute the connection between having choices and control over your daily work and overall job satisfaction. The people with more power to govern themselves will typically report that they are more satisfied with their jobs. This is why pairing can play a huge part both with picking who you work with and what you work on.
In response to some recent web browser related debates:
http://sachin.posterous.com/the-web-sucks
http://techcrunch.com/2010/04/30/joe-hewitt-web-development/
http://yehudakatz.com/2010/04/30/the-web-doesnt-suck-browsers-are-innovating/
The web has long since tried to help developers realize the [perhaps misguided] promise that you can write software once and run it anywhere without modification. This might have even seemed feasible when the only real consumer web-enabled device was a desktop or laptop PC with a fairly standard monitor resolution, keyboard, mouse - predictable. You could even bank on IE probably being the browser of choice at one point, like Netscape before it.
I recently returned from a trip to Egypt with Pivotal's own Lara Owen. Like all good tourists, we went and saw the Pyramids of Giza. Like far fewer tourists, we also went to Saqqara to see the Step Pyramid and then on to Dashur, home of the Bent Pyramid and the Red Pyramid.
In the 3rd Dynasty, the Step Pyramid is constructed under the rule of Djoser. The pyramid has entered the market. By the 4th Dynasty, under the rule of Snofru, six steps are no longer enough, users want seven steps and smooth sides.
In an attempt to meet these new market demands, the Bent Pyramid construction begins. Half way through, they realize they made a mistake, and adapt their plan accordingly by changing the angle down from 54° to 45°. The next attempt, still within Snofru's lifetime, becomes the gold standard of pyramids and is known as the Red Pyramid. With it's consistent sloping smooth sides and added height, this pyramid was fit for any king.
What I thought about, as you might have guessed by now, was the methodology used to construct each of these pyramids. In the case of the Step Pyramid form the 3rd Dynasty, it would be easy to see a king proclaim, "I want this kind of pyramid and I want it ready by the time I die." And he'll get something twenty years later that resembles what he wanted twenty years ago.
Snofru had a different plan. He was going to shake up the way people think about royal tombs. He was going to do something no one else had done. This man of foresight said to his people, "We will release early, and we will release often. We will have meetings along the way to reflect on how we have progressed, and we will then plan ahead only as far as is practical, adjusting as we go. Most importantly, we will trust each other such that mistakes can be made without causing great harm to the project." It was with this spirit that Snofru began work on the Bent Pyramid.
He didn't know what he was doing, there was no model to copy, no patterns to solve this problem. So he guessed 54°. And they built, and they talked and said "Hey Snofru, this looks great, but it won't be stable if we continue at this angle." To which Snofru probably replied, "I will trust your expertise here, can we make the angle less steep and see how that works out?" So 45° it was.
When the finished, they stood back and looked at the work they had done. It was taller, and it did have smooth sides, but it wasn't quite right. Snofru, being a wise king, knew that this was a great success.
- A taller pyramid could indeed be built.
- 45° was a sustainable angle
- He was still drawing breath and now had the knowledge to fully realize his goal.
Snofru still had plenty of time on his hands, and because he released early instead of letting construction drag on, he had new insight from the retrospective that he wouldn't possess otherwise. So he built the Red Pyramid with complete success.
Snofru was, in my opinion, the first adopter of Agile principles. His "employees" trusted him enough to be able to push back when the plan needed revising. He trusted them right back not to yank his chain about things being too steep. He made his mistakes up front, which taught him lessons about his domain, and it enabled him to be successful in the long run.
When I joined the project, we went from one pair, to two. Today, we're three pairs, six people strong. But the communication paths now are far more numerous than the one pair days.
An informal survey conducted earlier at Pivotal Labs asked "how often do you rotate pairs on your project?" The answer for the Best Buy Remix team is usually every two days, but three days is the hard stop. It was about the same when I worked on the Palm Pre apps. But back on Mavenlink, we rotated ever single day.
Working for Pivotal Labs is different than any other software shop I know. A big part of this is that it is easy to feel good about the product you're delivering to your client. Another reason is that we constantly challenge our own practices, ensuring that we continue to do the right things for the right reasons.