Friday, January 30, 2004

Portfolio Management - the AHP way!

My good friend and former colleague Martin Geddes explains why you can’t do portfolio management in a Fortune 1000 company without learning to make expert choices using Analytic Hierarchy Process (AHP).

There has been an ongoing thread in the TOC Experts group at Yahoo! on the topic of portfolio management and product selection. It’s one that interests me greatly. I dedicated only 2 chapters and briefly skimmed the surface on the topic of product and service mix - the little cousin of portfolio management in my book. I really feel that there is a yet to be written important book on product and portfolio management for agile software engineering waiting to be written. I need to learn a lot more and as I do I will share it in my own Yahoo! group.

Thursday, January 29, 2004

Back on the Buses

As I have mentioned before, I commute to downtown Seattle using the King Country Metro buses. Over New Year, KC Metro took delivery of some new rolling stock. These new coaches can be distinguished from the older ones because they have a low floor and only a single step into the main cabin. The low floor is achieved by moving the engine to the back of the bus where it is mounted vertically. There is no rear window in a low floor bus. In addition, the wheel arches of the front wheels protrude into the passenger cabin. This reduces the seating capacity.

So here is the Theory of Constraints explanation as to why low floor buses make sense most of the time, but why they don’t always make sense on my oft traveled routes - no.18, no.15 and no.17.

As I explained before, the usage of a public transport system is dependent on the frequency of service and reliability of that service to run on-time. With a frequent service which is punctual, a virtuous cycle develops where travelers use the service more and come to depend on it more. As soon as either frequency or punctuality drop off, the passengers go looking for their car keys and a vicious cycle has started. So systems thinking and constraint thinking go hand-in-hand to provide an efficient public transport system.

Now for the constraint thinking! The new low floor buses provide ease of access for those with a mobility challenge such as elderly people. It is easier to get on and off a low floor bus. It is also faster for elderly people to get on and off when there are less steps. For those in a wheelchair or using a walker, they require use of the lift. When the floor is lower, coupled to a self-lowering suspension, the lift will extend faster. In fact I timed it as 30 seconds faster to load a passenger on a low floor bus. Again as I explained before, timeliness is important to the service. The bus will suffer variance in schedule as it travels through traffic. A big driver of variance is how many people get on or off and how quickly they can pay their fare. Elderly and disabled people increase the variance on stops - particularly when the lift is used. Providing low floor buses provides a win-win. It is better quality of service for those who need the benefits of a low floor and it helps reduce variance which helps to keep the buses running on-time!

So low floor buses are a boon! Right?

As I mentioned, the low floor design, reduces seating capacity. In fact at least 8 seats are removed by the intruding wheel arches and the vertically mounted engine. This is not a problem when capacity is not the constraint. When the constraint is purely adherence to timetable and the bus is under-utilized then it is never a problem that 8 seats are no longer present. However, the routes no.15 and 18 and to a lesser extent 17 were chosen to be replaced by the future monorail. The reason for this choice is that routes 15 and 18 are the most heavily used routes in the city. During rush hour, the 15 and 18 buses are capacity constrained. It is common for the standing room to be full and for passengers to be turned away. The introduction of the low floored coaches has only exacerbated this problem.

So how can this broken constraint be elevated? Clearly reducing quality of service for elderly and disabled passengers is not the answer. The truth is that the monorail replacement cannot come soon enough. The monorail will provide enough capacity and by elevating (literally) above the traffic, variance is reduced and adherence to timetable is no longer a concern. Roll on December 2007!!!

Wednesday, January 28, 2004

Categories and Roles

Donald E. Baisley, publishes an article explaining Categories and Roles in Business Vocabulary, at the BR Community web site.

As regular readers will know, I talk often about Peter Coad (and others) work in defining business archetypes for use in UML and the Domain Neutral Component pattern of associations amongst those archetypes. Two archetypes - the blue one <<description>> and the yellow one <<role>> are relevant to the discussion in Baisley’s article.

For those familiar with color modeling, you might like to color Baisley’s article as an exercise. For those, not so sure, you might find this writing from a different world and a different perspective helps. For those who have never considered modeling or analyzing a business domain using the concepts of roles and categories/descriptions then you might like to try it.

Tuesday, January 27, 2004

Lost Comments

For some reason, comments to the post To Code or Not To Code, are not showing up. I believe this is a bug in HaloScan. So I’m making this new thread available for anyone else who wants to comment.

Anwar Haneef wrote: Its great to see that you can make the best of a situation that many line managers might see as a nightmare - having to get down and code. Learning from my experience with line managers, I’ve come to realize the importance of building a very strong (technical) foundation and taking the initiative to keep up to date with technology sufficiently enough to be able to ‘speak’ in the language of the developer when you really have to. Its unfortunate that some line managers don’t quite get this and get lost in murky high tech waters - having lost the wave, pushing technology ahead.

Doc McClenny countered: As a counterpoint…

Nothing is worse for team morale than a manager trying to use decayed technical skills to teach a team how to do something that they already do better.

Sometimes, getting outside technical help is better than a manager trying to still be technical.

I couldn’t agree more with Doc. It is really important that a manager knows his or her own limitations. Floundering about with decayed technical skills wouldn’t be leadership. OTOH if it is only a little language syntax that is out of date but the manager carries the weightier skills in design, transaction management, architecture and technical risk management then any language deficiencies can be countered by pairing with a strong language lawyer from the development team.

Sunday, January 25, 2004

Class Ownership #3 - Regular Integration

Class Ownership and Continuous Integration don’t mix!

However, class ownership and regular integration might be a best of both worlds solution!

As I mentioned, the other day, class ownership forces team working. However, there is a side effect to team working and the use of most popular version control and continuous integration tools - it is impossible for two team members to check-in code simultaneously! If two (or more) people have been collaborating on a single Feature and one is adding methods which the other must use, or indeed modifying method signatures from existing code, then when the first developer checks-in, the build will break. Not until the second (or subsequent) developer checks-in his updates will the continuous build recover.

The problem with continuous integration is that it overloads two concepts - check-in, a mechanism for safe storage, version history, and file sharing - with build, a mechanism for integration of the code. This becomes problematic when mixed with class ownership.

FDD has an explicit Promote-to-Build milestone for every Feature. What does this mean? It means simply that check-in can happen multiple times throughout the development of a Feature. Several owners can check-in and check-out as they see fit. In fact, check-in should happen every night. What happens if the developer is off sick tomorrow? Unless they have checked-in so that their secondary class owner can takeover, a Feature might get blocked. FDD relies on a 2-stage promotion process. Check-in happens to a revision labeled “dev” area in the version control. The Chief Programmer or Development Manager has the right to “promote to build” which is a process of relabeling check-ins. Only the revisions labeled “build” are built.

In FDD, the continuous integration process would run on the “build” revisions. As Work Packages of Features are only promoted to build (relabeled as “build” revisions) when the Work Package is complete and reviewed, then there is an inevitable delay between check-in and the basic integration test of compiling the build. This process might better be called regular integration. By encouraging the development of small batches, there is still basic integrated compile checking happening frequently to highlight problems early. This meets the spirit of the continuous integration movement in agile methods, whilst delivering the long term quality and integrity benefits of class ownership.