Thursday, July 08, 2004

Team Time Trial

America is fascinated with Lance Armstrong’s attempt to win a sixth Tour De France - and why not, what an achievement that would be! Even our local Komo 4 news in Seattle gives us a daily update while the Outdoor Life Network (OLN) channel on cable TV has virtual 24 hour coverage repeating the race coverage 4 times daily. So here are some topical thoughts on the Theory of Constraints and the Tour De France.

Yesterday July 7th saw Stage 4 of the race which was a 64 km team time trial Cambrai to Arras. In this stage, each team rides with up to 9 riders as a group but each team rides separately against the clock. Naturally, the fastest team wins. The time is set by the 5th rider to cross the line. The usual principle in team time trials is to keep the team together in a long line. One rider fights the wind and the other 8 hide in the slipstream. The rider at the front rotates every few hundred metres and thus the top speed is maintained and each rider doesn’t get too tired. Hiding in the slipstream can save up to 40% of a rider’s energy.

With around 45 kms to go Lance Armstrong’s team dropped one team member Benjamin Noval. Why? Another American rider and contender for the overall win is Tyler Hamilton. In the closing 20 kms Hamilton’s Phonak team dropped 4 riders and finished with only 5 men together. Why? Surely in both cases, it made more sense to keep the team together. In Hamilton’s case, earlier in the race he had waited for a rider who had a mechanical problem. So why change his mind later?

Quite simply, the constraint had moved!

When the constraint on top speed is the wind, then in TOC language the constraint is outside of the system and the system - the team of riders - must exploit it and subordinate to those exploitation decisions. The tactics for this are the standard tactic a team time trial - ride together in a long line, rotate the rider at the front as soon as the speed begins to drop off, conserve energy, keep the top speed as high as possible. However, sometimes the constraint will move inside the system. As soon as one or more of the riders in the team cannot maintain the pace of the rest, then that rider becomes the constraint. The team can only move at the speed of the slowest rider. The constraint is inside the system.

In both cases, Hamilton and Armstrong realized that they would go faster if they dropped the constraining rider(s) from their group. They made an on-the-fly decision to change tactic because they realized that the constraint on their productivity had moved. Noval who had been injured the day before in a crash, was evidently unable to maintain the pace with the rest of the US Postal team. Armstrong dropped him and left him to cycle almost 45 kms on his own at a speed around 8 kph slower than the rest of his team. Sometimes it is tough to be the leader or the manager but that’s what managers and leaders are paid for - to make the tough decisions. The US Postal team won the race and Armstrong assumed the over all lead in the Tour De France. He couldn’t have done so without understanding his constraint and making the correct exploitation and subordination decisions. He couldn’t have done so without being a strong leader. And he couldn’t have done so unless everyone on the team understood and believed in the goal - Lance Armstrong must finish as the over all winner in Paris after stage 20.

Wednesday, July 07, 2004

FDD and Legacy Code

I’ve been asked by a few readers to comment on how to use FDD with a legacy code base under maintenance. [There is an assumption in this post that the legacy code is still OO in nature such as a monolithic 1999 vintage EJB system]. This topic has come up at Jeff De Luca’s web site in the past - Maintenance & FDD. Daniel Vacanti and I have had a couple of experiences with FDD on legacy code bases over the last 5 years and my general advice to anyone undertaking a maintenance process and wanting to gain the benefits of a method like FDD, is that they should try to make as few changes to the FDD process as possible. FDD definitely works with maintenace projects. So how do you go about it?

First off - make a consensus decision that you want to move forward with FDD and give people time to mentally adjust to what that means. Adopt a norm that “We will adapt what we are doing to the FDD process.”

Next, consider the new maintenance requirements and work through the 5 steps - build a domain model (in color preferably), then create a Feature List and plan the project by the groupoings of those features. This is the basic Coad Method as described in Peter’s 1995 and 1997 books Object Models - strategies, patterns and applications. This should not change. The domain model provides the foundation for the communication mechanism in FDD. It provides the foundation for the quality assurance mechanisms such as design and code reviews.

So how do you reconcile the new model with the existing code? This seems to be the mental hurdle which causes many architects and developers to recoil and believe that FDD can’t be made to work for them. There are two strategies for this.

(a) Legacy Wrapper Facade

Take the legacy system and effectively end-of-life it by wrapping it in a facade of service calls, i.e. make an API for the legacy system. This isn’t always appropriate. It really only works when the new maintenance work is on the periphery of the existing code base. The new FDD system will talk to the existing system through an SI (System Interface) layer. All the features for the legacy wrapper and the SI classes in the new system would be listed on the feature list as SI features.

(b) Refactor the Model

Using a tool such as Borland Together generate a model for the existing code. Take that model and print it out - however, large! Then with a small team examine it and try to identify class archetypes and color them. Take the model for the new iteration and map it against the existing model and identify areas for refactoring such that the new classes will “fit” with the existing legacy. Write a feature list for the refactoring.

In both cases, there is a bucket of features allocated on the feature list for reworking the legacy. There is clearly a cost to this. Why is it worth making this investment?

It is assumed that the new code built with a Coad style domain model will be more robust, easier to maintain, more accepting of change, more flexible and ultimately the enabler of sustained momentum and higher project velocity in future iterations. You are paying now for improved velocity later. By surfacing the refactoring or system interface features, you are providing transparency into the process. It is then possible to make an informed and objective decision about whether the cost is worth paying.

[Martin Fowler discusses the re-write versus maintain and refactor approach in Strangler Application which appears to offer us some design strategies which would be compatible with color modeling. Fowler’s Events are Coad’s Moment-Interval archetypes whilst Fowler’s Assets are Coad’s Party|Place|Thing (green) archetypes.]

Tuesday, July 06, 2004

ChAD Friday July 9th

I’ll be speaking at the Chiacgo Agile Developers group meeting on July 9th at De Paul University. If you live in the Chicago area I hope to see you there. I’ll also be in Chicago until the 13th. If you’d like to hook up for chat drop me an email - dja @ the domain name of this site.

TOC and Variation

So after almost a month of posts about uncertainty and variation what is the point of all this Wheeler and Shewhart stuff and how does it relate to the Theory of Constraints?

Quite simply, understanding variation is necessary in order to follow TOC’s Steps 2 (Exploit the Constraint) and 3 (Subordinate everything else in the system to the decisions in step 2). All systems involving humans tend to be probabilistic and empirical in nature. There is natural variation. In order to protect a constraint, where it is a work unit, a function, a person, or some other resource, it is necessary to understand the variation of the constraint and variation of the material running through it - whether that material is knowledge or plastic explosive (some people may recall my dad worked in an explosives factory - fascinating stuff similar process to the manufacture of sausages at your local butcher shop, I digress) - in order that you can adequately buffer for protection. If you are going to subordinate other parts of your system or process to the constraint’s exploitation measures, then you need to understand the variation in other parts of the system so that something else doesn’t accidentally become the constraint simply because you didn’t leave enough slack in it to absorb its natural variation.

And so we have neatly tied TOC to Shewhart, Wheeler, Deming, the understanding of variation and its derivatives such as Six Sigma!

Friday, July 02, 2004

Lessons Learned from Eli #4

Lean and Six Sigma

How do Lean and Six Sigma interact with TOC? It is a question asked often. According to Eli Goldratt, TOC is the focusing mechanism for Lean and Six Sigma. In turn, they provide the mechanism for exploiting the constraint (TOC Step 2) and subordinating to the exploitation decision in step 2 (TOC Step 3).

For example, when the constraint is in the market, i.e. you can’t sell enough of what you make, then the exploitation requirement is that you achieve

1. Excellent Due Date Performance
2. Short Lead Time
3. Satisfactory Quality (not excessive quality)

and do all three within the consumer tolerance. What better mechanisms for this than Lean and Six Sigma with their roots in understanding variation, Six Sigma’s focus on reduction of variation, and Lean’s focus on elimination of waste and shortening of lead time?