Monday, April 30, 2007

Lean Leads to Software Engineering

Thursday, April 26, 2007

Heroes #1: Graeme Obree

For a while I’ve been thinking of doing a series on some my favorite management inspiration figures - my heroes of management, if you will. Well this first post isn’t about management, rather its about my other passion - biking.

Last week I got a ticket for the Seattle pre-screening of The Flying Scotsman, the story of Graeme Obree. The guys at my local bike store, BikeSport, respect my bicycle - a 1998 model Corratec TrialBow (though they mistook it for the Team Racing model like the one in the picture with Jan Ostegaard), either way a collectors item. The movie distributor had arranged to provide tickets to local bike shops and they decided I’d be one of the guys who might like to attend. They didn’t realize that I might very well have known Obree…

Graeme Obree is 18 months older than me. He grew up about 10 miles south of where I grew up. I never met him nor did I ever race against him - I didn’t race bikes until I lived in Singapore - but I knew people who did meet and race Obree. Most of all I remember the sinking feeling on couple of evening training rides in summer as a teenager when that “fast guy from Irvine” would come past me and my body had nothing to offer in response.

In 1993, with no real sponsorship, riding a home made bike, no team doctor, no nutritionist, no professional coach, the relatively unknown rank amateur Obree shocked the cycling world by breaking the Hour Record that had stood for 9 years and had been set at altitude in Mexico by Francesco Moser. For effect, Obree did this during the Tour De France and stole all the headlines in the French papers the next day. He went on to win the World Championship 4000m Pursuit that same year, breaking the World Record in the process. Later the UCI banned his riding position and disqualified him from the 1994 World Championships. Obree’s hour record had fallen to Chris Boardman. He went off home to Ayrshire, lick his wounds and came back to break the Hour Record again and in 1995 to win the World Championship again this time using a new riding position. Once, again the UCI banned it and reset the rules for the Hour Record, effectively erasing Obree’s achievements from the record books.

Obree briefly signed to a French professional team and was quickly fired. He disappeared from International cycling. He suffered from manic depression and attempted suicide. He was found at a remote farm house in Ayrshire dangling from a rope in 1998.

In recent years, at the age of 38 in 2004, Obree (seen left pictured on his home club web site, Fullarton Wheelers - observe the superior aerodynamic position) tried again to retake UCI Hour Record then held by Chris Boardman. He abandoned when he wasn’t going fast enough averaging only 47km per hour. At the age of 40, he finished 2nd in the Scottish 10 mile time trail championship and rode in the British national championship.

History hadn’t been favorable to Obree. Journalists unaware of his lifelong struggle with depression had written him off as a loser. At best a terrible underachiever. With his talent he was expected to have won a lot of professional titles including 1 day classic races. None of that came to him. He was never rich. What the movie does, is set the record straight. Obree was a winner. He achieved more than most people could ever dream of, and he overcame his illness to be the best in the World. [When I searched with Google looking for many of the articles that were critical of Obree, they’ve been obliterated by positive stories generated by the movie’s release in Britain and Europe and reviews of Obree’s autobiography. The movie’s producers have achieved their goal and fixed the historical record.] His achievement is all the more significant when you read how hard it was for Miguel Indurain - known as ‘The Extra Terrestrial’ because of his huge lung capacity - to beat Obree’s 2nd One Hour mark. American readers might like to reflect that Lance Armstrong is the only significant Tour De France champion who has never taken the Hour Record. He hasn’t even attempted it. That Obree managed his achievements with no funding and no professional help, on a home made bike, is amazing. In an era when it is likely that most professional cyclists were taking drugs, Obree was simply too poor to be cheating.

The movie doesn’t get deeply in to the politics of cycling, nor does it offer us cog heads a lot of the fine detail. Obree’s training methods are not explored. Details such as his low riding cadence and his huge gearing are never discussed. The movie fails to show just how scientifically he approached his training or his diet. But it achieves its goal of defining him as a winner and a hero.

If there is a management failing in the Obree story, it is the notion that his homemade bicycle was a liability and prevented him from receiving serious sponsorship after his first World record. His innovation of using sealed bearings became common place within a few years. The idea that the parts came from a used washing machine need not have been a liability. It should have been seen as an opportunity. Also as an expatriot Scot I’m left wondering what would have happened if Obree had been prepared to quit Scotland and his home town in Ayrshire after he first came to international aclaim. If he’d had an American equipment sponsor and lived in American with American health care could the story after 1993 been very different? We’ll never know! Unlike me, Graeme still lives in Ayrshire and there is a lot to be valued in that.

If you are a cog head like me - go see the movie. You’ll love it! If you like underdog movies - the home farm boy from Iowa who throws a no-hitter in his first Major League game - then you’ll enjoy it too. If you’re a Jonny Lee Miller fan, go see it. Miller is great casting as Obree! If you suffer from depression or bipolar disorder and need some inspiration, then you have to see this movie. Most of all, if you are a regular reader of Agile Management and you’d like to hear people who talk like me, see the geography and architecture of my youth, and understand the West of Scotland Presbyterian culture that molded me then you can’t afford to miss it!

The Flying Scotsman - in theaters from May 4th in the USA. Technorati tag: Graeme+Obree, Flying+Scotsman

Wednesday, April 18, 2007

Book Review: Design for Trustworthy Software

Prentice Hall were kind enough to send me a copy of Design for Trustworthy Computing, after it caught my eye at the SEPG conference. It looked liked it was packed with quality material that I’d never seen aggregated in to a software book - techniques including TRIZ, AHP and QFD were all mentioned. I flicked through the book on the bus in to work last week and was impressed enough to hand it off to Corey Ladas in our Process Engineering team. Here is Corey’s in-depth review as today’s Guest Blogger at Agile Management…

This book was inevitable. It’s essentially Design for Six Sigma for Software, and as far as DFSS books go, this is a good one. The audience for this book is on the upper end of technical management, people who can see the big picture and distill practical guidance from abstract methodology. Engineering professors, professional methodologists, senior architects or program managers, or directors or vice presidents of engineering will get the most out of this book. Your typical individual engineers or line managers are probably not going to make much sense of this unless they have a particular interest in methodology (i.e. your future managers).

Historically, software engineering has invested most of its quality control effort into verifying systems against requirements. This is probably due to the inherently mathematical nature of the domain and its participants. There are powerful methods for analyzing both the syntax and semantics of software design specifications (i.e. source code) with respect to requirements. Almost as a side effect, the discipline has also produced related methods for verifying the correctness of requirements specifications themselves, at least at the level of syntax. But software engineering has severely neglected the fuzzy customer end of the relationship for many years. All the formal methods in the world are still subject to “garbage in, garbage out,” and traditional software requirements analysis methods produce a great deal of garbage indeed.

Consequently, software got stuck in the “conformance to requirements” mentality of quality control for decades. Only recently has the software development world begun to consider “fitness for use” with any kind of systematic seriousness, and then often at the expense of engineering rigor. By contrast, Japanese product developers began to embrace more customer focused methods since at least the 1960’s and the rest of the world has been chasing them ever since. Design for Six Sigma (and its precursor in Quality Function Deployment) represents the best of current thought into the importance of comprehensive understanding of the customer and early customer validation of requirements. DFSS also brings a much more realistic statistical understanding of product quality, in contrast to the formal/logical software paradigm.

There are two likely approaches to writing a DFSS for Software book. One is to start with a conventional software engineering model and terminology and pull DFSS ideas into it. Another is to adopt the point of view of DFSS-style product development and map it to software development. Design for Trustworthy Software is an example of the latter. The book aims to be fairly comprehensive in its scope, including both project and organizational guidance as well as detailed descriptions of DFSS practices and their application to software development. The book is organized into 5 parts, and for a book this size, a few well-placed tape flags can do wonders for navigational context. If you already know why you want to commit to a Trustworthy Software initiative, then parts 2 and 3 will be the most useful, as they contain the most practical direction on “what to to and when to do it.” My only lament here is the omission of Axiomatic Design, which represents the most rigorous thinking in DFSS and is highly applicable to software development.

A few bold thinkers have been integrating the two paradigms of Product Development and Software Engineering for a while now, but this book represents one of the first truly definitive statements about a new and more comprehensive view of software product quality. Software engineering has always suffered from a sense of skepticism about its worthiness as an engineering discipline. For the first time, reconciliation with other engineering disciplines seems feasible, with the language of Design for Six Sigma as the common ground.

For the appropriate audience, this book is highly recommended.

Tuesday, April 10, 2007

Pair Programming in 1975

No really!

This article from Crosstalk in 1996 is a positive gold mine. Scroll down to the section of the Two Person Team.

The two-person (2P) team implements the adage “Two heads are better than one.” When this concept was first implemented in 1975, there was great concern the productivity gain could never offset the additional resource expense. The two-person approach places two engineers or two programmers in the same location (office, cubicle, etc.) with one workstation and one problem to solve. The team is not allowed to divide the task but produces the design, code, and documentation as if the team was a single individual.

I wonder how many XP zealots I’ve just upset by bringing this to wider attention? Technorati tag: Agile, David+Anderson,, XP, Extreme+Programming

Why Aren’t Managers Paid More?

In Thinking for Living, Thomas H. Davenport argues that managers of knowledge workers should be paid a premium for assuming the position as manager and letting go of the relatively safety and security of their individual contributor knowledge worker job. His reasoning is simple - managing and organizing knowledge workers is so vital to their productivity - self-organization and empowerment only go so far then management has to step in. However, the first management level job requires the individual to take a huge personal risk - abandon the skill set that made them successful and learn a whole new skill set as a manager. In order to attract the correct candidates in to management goes his thinking, it is necessary to pay a premium. How much of a premium is hard to say but 10%-20% would seem appropriate.

The interesting thing is that compensation professionals tell me that a premium salary is not supported by the market for managers in software engineering. I think that there is one main reason for this and a number of secondary reasons that might indicate a root cause for the problem. The first reason is basic economics and the fact that uncertainty in the nature of the work forces managers to maintain a flexible workforce of contingent labor (contractors). This is typically 10%-50% of the resource pool. The contingent nature of contract labor requires that a premium is paid for the hourly paid contract labor. Good people, confident in their technical skills and their ability to renew and refresh those skills regularly can earn a premium as contractors. Often earning more than middle managers and junior executives. Put another way, a geek can earn more as a contractor than he or she could make suffering through 10 years of climbing the corporate ladder as a manager. Hence, permanent full time individual contributor knowledge worker jobs fetch higher rates too. And as such, there is no premium for management. In fact, the market would suggest that managers should really be paid less!!!

Clearly this is a problem! If knowledge worker productivity is primarily a factor of effective management - and Barry Boehm made a science of this discovery in software engineering - then there is a conflict when the open market will not remunerate managers appropriately. What is causing this conflict?

I feel there may be a number of reasons and feel free to comment and add to my list [Update: Aarrrggghhhh, Murphy’s Law - this would have to be a post where that bug in Haloscan kicks in and the comment option is unavailable. If you want to leave a comment use the comment box for the previous post. Thanks.] First, I feel that geeks always look for a technical solution to a problem, before they will pursue a people or process solution to a problem - in other words, tools over operational innovation or sociological or psychological changes within a workforce. If the answer is always to deploy a new software-based tool, then the demand will always be for high-end geeks who can make the best software. Secondly, technical innovation and problem solving is valued over operational innovation and an ability to quantitatively management to a plan. All that tribal individual value is bundled in to an ability to create great product innovation and solve significant problems in computer science rather than process innovation and the soft skills it takes as a manager to motivate a team.

In conclusion, I feel that if we are to deliver on Davenport’s vision that good management will come from offering a premium for knowledge workers to make the leap to a new skill set then we must first start to value management skills more highly. In order to value management skills more highly, I believe that we must embrace Barry Boehm’s observation from 25 years ago - poor management can increase software costs more than any other factor. So far, we’re an industry in denial of this basic truth. Until we face our own brutal reality - that good management works and bad management hurts - then there is little hope for fixing the situation.

Related blog post: Social Networking for a Living, Why Good Managers Still Matter to Agile Development
External Links: Crosstalk article from 1996, Management Impact on Software Cost and Schedule  Technorati tag: Agile, David+Anderson, Software+engineering, Thinking+Living, Thomas+Davenport, Management, Knowledge+Worker