Martin Fowler, Alistair Cockburn, and Optimism

The effort to make Software Engineering actually live up to the 'Engineering' part has been greatly helped by Martin Fowler's book on refactoring. Martin recently posted about his decision to not participate in an effort by others in the industry, not lacking in optimism, to define a common process for software development.

Martin Fowler declined to get involved in a similar effort and for the same reason.  The key quote is,

“Why this is so was primarily crystallized for me by Alistair Cockburn who explained that since people are the central element in software development, and people are inherently non-linear and unpredictable - such an effort is fundamentally doomed.”

While my previous post about Alistair's paper covers much of the same ground I felt it was worthy of an update.  There will always be souls who crave consistency just as there will always be salesmen willing to offer the illusion of it.  Facing our own nature is one of life's hardest lessons. Some of those who ignore the human factor are optimists seeking to improve their chances of consistency, which has driven many towards the latest and greatest geegaw, a new language, a new GUI, a new design tool. Others are simply deluding themselves in the hopes that if only people would sit up and fly right (read this to mean 'do it their way') all our problems would be solved. 

Studying the process of computer programming has been around for decades.   Even so, we still have trouble internalizing human foibles - people aren't predictable and follow "standards" about as well as a random-walk.  So the most successful way to get people to be consistent is to lead by example, blaze a trail ahead and show them the way.  In this manner Extreme Programming was its own worst enemy and its own best cheerleader. By showing how a set of practices work in situ, it created a much-needed focus. The "Waterfall" model was the favorite whipping-boy, essentially dead, and the iterative approach was in its infancy.  So XP served as a lightning-rod for discussions on the craft of software development.  It provided an example of practices that could be emulated and provided an easy target for the doubters, disbelievers, and denialists; no doubt the negativity coming from the critics was channeling  their innate understanding of the darkside of human behavior.

While Extreme Programming hasn't become the standard development model, that doesn't mean it failed.  When the history of Software Development is written, XP will be given credit for re-introducing the most important factor; not tools nor process, but people.

Context as a commodity

How much context do you need to do your job?  Can we quantify context in any way?

Jeff Atwood has mentioned that he doesn’t shut his machine down every night.  He wants his environment to be as he left it at the end of the previous coding session.  Getting all the apps, tools or other windows opened to the right place takes not only CPU time but mental energy, aka context. 

Some jobs require no context, for example a bank teller can walk in to work on Tuesday and not need to remember any of the transactions that took place on Monday.  Contrast that with a novelist in the middle of writing a new book, let’s say writing the next chapter not editing anything.  They need to remember all the characters, their personalities, the existing story, and in what ways the plot threads are to interact in the new material.

Another good contrast is a professional athlete.  A pro baseball player doesn’t need to remember what happened in yesterday’s game in order to pitch a strike, hit a home-run, or execute a double-play.  The limited context that does appear has to do with the optimizing performance.  A pitcher does need to know the preferences and history of the batter who is at the plate, just like the batter needs to know if the pitcher has a wicked slider. 

Companies want to be “green” these days and have instituted policies to shutdown computers overnight.  This may be pennywise and pound foolish.  Here’s why.  A consultant gets paid $50/hr and it takes 30 minutes to get their workspace ready after an overnight shutdown lasting from 5pm to 8am the next day, 15 hours.  A conservative energy estimate would be if electricity costs $0.25 a kilowatt hour multiplied by 15 hours for a cost of $3.75.  So $25 is spent trying to save $3.75.  That’s motivation to use the hibernate feature at a minimum. It also is a very simple way to quantify the cost of context.

Can we describe jobs by how much context is required?  If so, is there a relationship between  the amount of context needed and the average salary?  Those are interesting questions, maybe I’ll cover those in a later post.