Monday, July 29, 2013

Technical Friction

While working on a roadmap for the future of our products at B2b2dot0, I realized we needed to have a consistent way of prioritizing internal efforts. Several of our internal efforts require modifications to fundamental pieces of our current products and processes.  So much so that it would require moving slower on current "billable" work. Justifying that level of structural change is difficult, especially at a startup where bandwidth is at a premium. But we also can not forget to spend time on increasing efficiency.

Each of these changes represented a certain risk, but they also offered a great benefit to all future work and efforts. Lean methodologies teach us about constraints and maximizing flow through constraints. In thinking about flow, I realized it's about friction. When there is high friction it becomes hard for things to flow through the system. If we can reduce friction, we increase flow.

Technical Friction is the resistance that all improvements encounter from existing technical infrastructure (and culture). We have all encountered this before, typically in the form or we can't do X because of Y.

Reduce technical friction. Aspire to be a polar bear on ice.
In identifying Technical Friction it became obvious how to prioritize internal efforts. The projects that reduced the most amount of friction deserved the most amount of attention. Simple enough. But what about reducing friction in a system that is currently running, receives little to no updates, and works as is? Reducing friction is those systems has low ROI and would more than likely introduce more work into the system as most systems that fit that description are fragile and difficult to test. So for the purposes of prioritizing it is also important to consider the flow and utilization of the component that has high friction.

This helps. The roadmap is now clearer and we can start moving by focusing on reducing friction in the systems that are constantly moving and changing. The goal is not to start moving, but to continue moving with low friction.

Thursday, July 4, 2013

Benefits and Positive Value of Pair Programming

After reading High costs and negative value of pair programming, i just had to write a post about the Benefits and Positive Value of Pair Programming.
Where to start? How about a quick statement to debunk Capers Jones analysis of Pair Programming. Capers uses 4 data tables to statistically prove pair programming invaluable and expensive. The basis for all the data is LOC (lines of code). LOC is a vanity metric, which only serves to document the current state of a product, but offers no insight into how we got here or what to do next. To borrow from Scott Bradley's blog post on Cohort Analysis,

vanity metrics give the “rosiest possible picture” of a startup’s progress, but does not track how people are actually interacting with the application.
That is exactly what LOC are, a vanity metric that offers no insight into what is really happening.So how should we measure the effectiveness of Pair Programming? Great question! Let's discuss Actionable Metrics. Actionable metrics tie specific and repeatable actions to observed results. Agile teams are full of repeatable actions, the smallest being Red Green Refactor up to Iteration Planning and on to Release Planning. During the Red, Green, Refactor cycle a pair is constantly inspecting the code and reacting to it. Capers cites that lone programmers produce 20 LOC/hr, while pairs only produce 15 LOC/hr. That 5 LOC/hr less is a direct result of constantly refactoring and evolving the code. Those 15 lines of code are going to be more maintainable and easier to hand off to another developer than the 20 LOC written by a solo programmer that has not been reviewed by a peer. Not too mention you now have cross pollination and not just one developer can maintain those 15 lines, but now at least 2 developers can reducing your single point of failure.

What other actionable metrics can we observe about pairing? How about delivery of features? It's repeatable and produces a result. Features may differ across teams and projects. Based solely on my experience pairing on large teams at companies like Progressive and Nationwide to small teams at startup companies like Save Love Give, the teams that paired effectively produced features more often and of higher quality with less defects. Those teams also exhibited a higher degree of cohesiveness and shared understanding that allowed them to be more effective in other aspects of the project, not just programming. The teams I have been on that have not paired or utilized what I'd call "partner programming" had to rely lengthy inspection processes and larger QA teams to ensure a higher degree of quality. The non-pairing teams also suffered from the side effects of turnover. Whenever a developer would leave the project, code produced by that developer immediately became more costly to extend and maintain.

Speaking of turnover and changes within a team, one less often mentioned benefit of pairing is easier onboarding of new team members. New team members become contributors day one, unlike non-pairing teams where new members must endure weeks if not months of learning standards, development process, code base, etc. Pairing teams are able to introduce new members to standards, process, code base, etc as they are working "hands on" in the code base.

So why would a team not pair? Culture. A culture that promotes strong egos, limited collaboration, and creates silos will certainly struggle with pairing. In order to pair the team needs to commit to setting their egos aside and working as a team. Even the most senior developer has something to learn from the youngest of developers!

The most difficult thing about writing this post is keeping it focused on solely pairing and ignoring other process changes that typically accompany teams that pair; TDD, iterative development cycles, and continuous integration among other things. Pairing is a process change. Actually it's a social change in your team culture. Your entire team needs to be open to that change. In 2002 I was part of a team that underwent an agile transformation and took on the entire book of eXtreme Programming practices. It took awhile, but the entire team remained open to the change and in the end we delivered some outstanding software ahead of schedule without working crazy hours. It turned out to be a project I frequently refer to when I describe the ideal scenario. We went from changing pairs a 1-2 day basis to multiple times per day as it made sense.

Just because you do not pair does not make you evil. Well not entirely evil :) It just means you have a different preference than I do. I respect your skills, however myself and others have experienced the benefits of pairing and prefer to work on teams that are open to collaboration and pairing as they can deliver much more value in less time.