Less Post More GET

Many articles have been written on the benefits of pair programming.  Often, (including the wikipedia article) the focus is on the typing aspect of programming – the speed at which code is created as well as the real time review of what is typed.  I believe this is one of the least important aspects of pair programming.

Programming is more about Design than Typing

Over the years I’ve noticed a difference between great programmers and average ones.

Average programmers are often seen typing.

Great programmers are often seen staring at code.

The reason, it seems, is because great programmers are thinking bigger.  They’re thinking about dryness, code consolidation, reuse, simplicity, using the existing framework, and a lot of other things than the specific tracker task they’ve been assigned.  Average programmers focus more on simply creating the code and tests for that task.  As a percentage of their work, average programmers type more.

Thus, focusing on the typing aspect of programming is biased toward the mediocre. It is the “small lever” within software development.  The big lever, the one that effects the long term cost of software development and maintenance is design.  And design comes from thinking.

Design (and thinking) is improved by dialogue

The real power of pair programming comes about due to the dialogue between the developers.  In order to present a design idea, the developer needs to put his/her idea into words and that process alone is often very valuable.  It is very easy to have an idea about how to solve something, yet gloss over some of the details or complex issues.  By taking a vague design thought and putting it into words, the person with the idea is actually learning about his/her idea. Obviously,  this process of verbalizing a design is usually missing when working solo and often a developer will simply head out in a “direction” confident they will figure out the details as they proceed.  With pair programming, a pair usually doesn’t allow this.

This verbalizing is inherently a good thought process.  The gaps in your thinking are exposed.

Along with discussing the solution design, the developer also likely will state their assumptions about why they think something should be done.  The assumptions could be about risks, costs, testability, etc.  And again, that dialogue between developers leads to further knowledge transfer and understanding.

Here’s a quote from The Costs and Benefits of Pair Programming

We often came up with different ideas about how the design should go and the result of arguing over which one was better often led to a truly superior hybrid design.

One last note about design.  I have found that pair programming tends to keep developers near the minimum of the cost curve (written about in Line Count and Maintenance Cost) instead of the arcane and wordy areas of the graph.

To sum it up, forget about all the nitpicky stuff in pair programming, that is not the long lever. It’s about quality and maintainability of software, but that will only happen if the developers are truly pair programming and not simply sitting together at the same keyboard.  But that’s a different post.

Lately I’ve been reading a lot of software development articles which use the words Lean and Agile as if they’re synonyms.

They aren’t.

I’ve been implementing both lean and agile processes since the early 90′s.  The concepts aren’t new, but they are relatively new to the software development world.  I’ve read about and taught TPS, SMED, and many other parts of lean production as well as many of the concepts used in agile manufacturing.  Their application to software is incredibly similar.

Lean is an inward focus.

Lean is a measure of the entity separate from its customers and historically is a measurement of waste.  Reduce waste and you are more lean.  The Toyota Production System (one of the oldest lean manufacturing system) has a constant focus on the elimination of waste.

Lean is loved by many executives because it conforms to the “world as machine” view. Taylorism, and it’s descendants such as business process re-engineering, have viewed the business entity and its processes (and the larger scale systems the organization exists within) from a mindset of planning and control – again, a world view most managers seem to prefer.

Agile is an outward focus.

Agile is dirty, organic, unknowable, unplannable, which makes managers and executives uncomfortable.

To be Agile, you do need to be somewhat lean, but the leanness is FOR agility, not the goal.  The difference is important.

Agile is measured not with internal measurements, but as a measure of how well the entity responds to changes in the external environment.  Waste and leanness are not the goal and as Eli Goldrat has shown time and time again, being more lean in the wrong places can make you much, much less agile.

It’s important to understand why agility has become so important over the last several decades.  It’s due to the continual shortening of product life cycles, customer order cycles, and the increase of product competition due to information exchange.  No longer can you release a product once every few years.  Even the idea of software versions is becoming somewhat obsolete (what “version” is the google search engine?).

Which to focus on?

I spend most of my time in the web world where agility, the ability to adapt to a changing competitive landscape, is the number one competitive advantage for a software firm.

Agility is customer focused and these days the customer is king.

So I choose agility over leanness every day.  It isn’t even close.

We all know that the less lines of code (SLOC), the lower the maintenance cost, right?  Not quite.  As with most things in this world, there exist marginal returns in the pursuit of brevity.

Over the past few years I’ve been working a lot more with Ruby and the Rails framework.  I’m not sure why, but there seems to be a social norm in the community of impressing others by consolidating code to as few lines as possible (often just one) with the (mistaken) belief that the code is better.  And that sometimes makes me feel like this.

Those programmers that create some of this amazing, yet arcane code are usually some of the best programmers I’ve ever worked with.

The problem is that they’re often misguided in this pursuit of brevity.

The relationship is probably not linear and there is likely not only diminishing marginal returns (which are almost always inescapable), but there is likely a negative relationship at some point.  The reason is that although the advanced programmer can handle the complexity of the “arcane” lines of code, those that maintain code are often not the ones writing it – specifically and also in skill level.  The more arcane the code is, the more time it will take those maintaining the code to understand it.

The relationship is probably like this graph.

It’s been my experience that good programmers do not need to be reminded of writing DRY and concise code.  Quite the opposite.  As a project manager, I believe it is necessary to inform and remind those great programmers of the potential for increasing costs due to an overemphasis on the reduction of lines of code.  Strange but true.