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.

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!!! :-)

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.

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.

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.

Code reviewing can be revealing! This can be especially true when done on a project which is a little unusual or run under stressed circumstances.

As I pointed out yesterday, class ownership introduces a constraint. When code needs to be written in a hurry, the class owner may not be available. There are two choices: wait for the class owner to free up; or allow a non-owner to check-out the class and make an update. When you are against the gun, there is little choice - break the class ownership constraint.

However, there is a price to pay. This price is not immediately obvious. In fact the systems cycle before it becomes an issue is so delayed and far removed that the cause and effect are hard to associate. Nevertheless, the quality of a class will atrophy unless the code is peer reviewed by knowledgeable team members. I found a great little example of this recently. A developer had opened another's class and added a very short method to complete a sequence. The method directly accessed a member variable (private attribute) of the class. Elsewhere there was a friendly scoped accessor method. All the rest of the class was using this method. Why? Naturally, the class owner had a reason - in a future release of the software, the attribute would not be accessed but calculated by calling out over the object model to other classes. By accessing the variable directly a potential future defect was introduced. This would inevitably cause some head-scratching later on and it is unlikely that enough information would have been captured in comments or design documents to really explain why something was one way and something else another.

The point in this example is that here is one small isolated incident. When you allow anyone on a team (particularly a bigger team) to edit any class for any purpose, you will quickly lose design integrity of the class. Paul Szego calls this "losing the Zen of the class".

It is truly important that classes themselves are considered components and that as such they are designed with the rigor which goes into larger components. This is best done by having one architect* for the component - one owner for the class.

[*Reference: Brooks, Frederick, The Mythical Man Month, Addison Wesley 1995, Chapter 4 Aristocracy, Democracy and System Design]

Feature Driven Development believes in class ownership - the notion that a named developer (or perhaps a primary and secondary choice) is selected to "own" a class. Only that developer will write code in that class. This creates a constraint and a potential bottleneck. Other agile methods do not believe in class ownership. My recent journey back to coding has reminded me why class ownership is important and I feel that a series of short blog entries is required. First up - Class Ownership Forces Teamwork!

Quite simply, class ownership necessitates the idea of a Feature Team. A virtual team which forms to design and build a small batch of Features which touch the same classes. Class ownership forces the owners to work together to design sequence diagrams and to agree the interfaces/method calls between the classes. This team thinking activity improves the quality of the design. It also improves the social and communication skills of the participants and helps them to build a camaraderie and mutual respect.

The alternative in many agile methods is one individual per Feature/Story/Task. This encourages the individual to design on their own. This leads to a poorer quality design (on the average) and valuable opportunities for team working are missed.

I was once (about 2 years ago) asked to assess a team I had recently met. They were doing some XP practices but otherwise it was chaos. My inquisitor was a psychologist. My response to his innocuous question, "What do you think of the team?" took him by surprise. My reply, "They are a group of individuals. There is no team."

I don't know whether the - one individual owns and is responsible for a feature and codes it from start to finish - was the only reason for this group work rather than team think, but I remain convinced it was a contributing factor.

Ever since I read The Tipping Point by Malcolm Gladwell, I've been toying with the concept of the role of manager as permission giver.

On pages 223 through 230 Gladwell talks about "Tipping People" - or permission givers. He uses very negative examples such as committing suicide and adopting smoking (as a teenager) but the concept can be applied positively too. People can tip the balance and cause a cascade of behavioral change through leading by example or giving permission. A line manager can act as this tipping person to change both the behavior of his staff but also the performance of his organization. The manager can change the culture by giving permission to change it.

Manager: Quality is poor! You should start code reviews before check-in
Developer: But we have no time to do code reviews!
Manager: I give you permission to take the time to do code reviews. Please start them.

Manager: Scaling this project is difficult. It takes too long to bring new people up-to-speed. You should produce design documents.
Developer: But we have no time to do designs!
Manager: I give you permission to take the time to do designs.

Manager: The design documents and finished code do not match. You should do design and code reviews.
Developer: But we have no time to do reviews and keep documentation in sync!
Manager: I will get you a tool which keep the code and design in sync. I give you permission to use the tool to the fullest of its capabilities. I give you permission to take the time to learn the tool and I further give you permission to take the time to perform reviews to insure that it is happening.

...and so on.

One big caveat to this "manager as permission giver", is the idea that the line manager must have gained the right to give permission from more senior management. The more senior managers may not be "permission givers" themselves and hence, in order to change behavior, the line manager may need to pre-emptively up-manage the situation. I recommend doing this by painting the current reality, [In TOC language - the CRT or current reality tree], and then by showing a vision of the future reality [the FRT - or future reality tree] and then by presenting a series of actions to change the CRT to the FRT. It is important to get buy-off on this process and to ask that, whilst the change is happening, senior management does not interfere. Change always causes initial chaos. Things always get worse before they get better. In "Agile Management..." I refer to this as the J-Curve effect. Giving permission isn't a magic cure but it is a good way to change a culture and to re-invent the mental model of the management in the minds of the developers doing the real work.

[If Phil Bradley is reading this - don't worry Phil I bought a new copy of the book :-)]

Recently I've been coding!

Back in the days when I worked at IBM as a contract coder - in the mid 1990's - my line managers were both young and recently promoted to their first management job. The management training involved as many as 5 weeks away from the team and was referred to as "the brain washing" by the former colleagues (now staff) of the new boss. One of the key tenets which was drilled into these young managers was "thou shalt never code again".

The position of line manager is key in any firm. The line manager is the one who manages the economic engine of the company. Without good line management, there is no business. The transition from individual contributor to line manager is also perhaps the most difficult and the most important for any business. For the first time, new line managers must learn to live vicariously through their staff. They must learn to coach the best performance out of their staff and to accept that some jobs will never be done as well as they would have liked them to be done or might have done themselves. This behavior of accepting life as a vicarious pursuit and learning to accept "good enough" rather than "perfect" is a measure of how well a manager is progressing and something on which further promotions to higher levels are measured.

It seems obvious then that if former developers are to learn to live vicariously, they must never code again. The temptation to "just do it" might otherwise be too great and they will never be good managers - always down in the noise and not defining the governing rules for their systems and the metrics with which to monitor and control them.

However, management is all very well but occasionally the troops need leadership. Developers need to be shown the way. This is particularly likely in new and uncertain territory. The greater the uncertainty - the greater the leadership required. Uncertainty can be caused by the domain - a new market being entered, or the technology, or the tools being used, or the working practices being adopted. In any or all of these circumstances, if the manager has the hands-on experience then it makes sense to lead by example.

When introducing FDD, for example, don't be afraid to lead a Feature Team as Chief Programmer! Don't be afraid to demonstrate how to Design-By-Feature by convening a Feature Team and facilitating the drawing of a Sequence Diagram! Don't be afraid to hold a code review! When developers are unsure of how to implement behaviors such as "blue" <<description>> classes on a domain model, don't be afraid to pair-program with a developer to make it happen. Pair programming is perfectly acceptable in FDD as part of the early lifecycle of a project whilst the architecture and design templates are being created. Don't be afraid to fuzzy the line between Step 1 - Build a Domain Model and Step 4 - Design by Feature. It doesn't matter if you have to go and build a dozen Features to prove a model. If seeing is believing then make your development team believe. Lead them to belief through example. Don't let "analysis paralysis" bog you down. Don't let subjective debate and belief cost you inertia and velocity. Lead by example.

It is OK for managers to code when they are leading! Once momentum builds and the team feels comfortable then the manager can quietly slip back into the vicarious life of monitoring metrics.

I was unaware that Larry Constantine published any new material on coupling in the 1990's. He switched his interest to UI design. However, along with one of Larry's colleagues from University of Sydney, B. Henderson-Sellers and Ian Graham from the UK. He published this paper, Coupling and Cohesion (towards a valid metrics suite for object-oriented analysis and design) [PDF] in 1996. 

This is heavyweight stuff but a must read for anyone who claims to be knowledgeable about good OO design, analysis or architecture.

Blogging has been light recently as I am deeply ensconced in architecting and developing a new product. I'm too tired when I get home to think about turning on my PC. I've been down deep and dirty in FDD process and actually pair-programming with developers to get traction in the project. Lots of fun! I'd forgotten how much I like coding.

I'm thinking of adding some history questions to my interview script. It is said that those who refuse to learn from history are condemned to repeat it. When you are paid to make software for a living, there is no time for waste on relearning the mistakes others made 30 or 40 years ago.

One gem from the last week, "Who is Ed Yourdon?" On another more serious note though, I am dismayed by the lack of knowledge of the history and development of computer science and software engineering amongst younger developers who started their careers in the 1990's. Just basic things like the knowledge that procedural languages came before functional languages. Functional languages produced more flexible results because they were less tightly coupled. Then, that leads to "What is coupling". Ah hem! Ever heard of Larry Constantine? and so it goes. What's the basic history of OO languages and OO design and analysis. Who were the main authors? and what are the key findings in the field?

[For those who don't know the answer to the above questions, Structured Design by Edward Yourdon and Larry Constantine from 1979 based on papers they published throughout the 1970's]

As I noted last week, many more recent developments are grounded in basic principles such as the Law of Demeter. Without an understanding of the history of how these principles evolved and the tradeoffs, developers fail to make informed design choices. Often trying to communicate the deficiencies in a design is impossible because the developer lacks the foundation knowledge on which an explanation can be built.

Steve McConnell laments about this lack of depth and history in Professional Software Development. I fully agree with him. History lessons ought to be a foundational part of any degree in computer science or software engineering. Employers should look for an understanding of the history and evolution of the discipline before hiring new engineers. Only by insisting that there is no room in the industry for engineers who do not know the foundations, will employers gain the benefits through improved productivity.

My publisher has told me that they are about reprint the book. This is great news. It means sales must be steady and well above my own humble expectations. I didn't expect a reprint for about 18 months but it is happening after 4 months.

The advantage of reprints is that you get to fix minor mistakes in the first print run. Mistakes such as typographic errors, spelling and punctuation as well as text on images. The downside of this is that it takes a rigorous reading of the book to find them all. If you have the book and would like to volunteer to read a single chapter of the book noting page, paragraph and line of any errors I would really like to hear from you. Please email me using the address on the back cover of the book.

Martin Fowler underscoring the point I made the other day that a good functional architecture (a.k.a. a properly encapsulated OO design with minimal dependencies) goes hand-in-hand with iterative or incremental development.

To this end, I've been banging the drum about the Law of Demeter and why it is important in step 4 - Design by Feature in FDD. Coupled with a good DNC-Archetype model from step 1 - Build a Domain Model - proper use of the Law of Demeter reduces dependencies in the object model and minimizes refactoring during the iterative CPWPs of steps 4 and 5. Minimizing dependencies makes it much easier to carve up your domain model into components, packages, Session Beans and so forth, later. This allows componentization to be postponed until during the project and eliminates the need a BDUF (Big Design Up Front) top-down design of packages or components.

Bottom Line: increased skill in OO reduces refactoring, allows development to start earlier, improves results from iterative or incremental development, reduces the S-curve effect of a slowing production rate later in the project.

Rebecca Wirfs-Brock's thoughts on how to go about becoming an agile designer - Skills for the Agile Designer [PDF].

This is really an interesting mix of stuff. References to Coad's Archetypes and Steve Palmer also gets a mention. This is the first time I've seen work attempting to merge Coad and Wirfs-Brock material. [Peter and Rebecca are widely regarded as the two best domain modelers - at least of the 1990s - because they spent the most time out in the field building real models for real big companies.] Also cited in this presentation: Martin Fowler, Objectory/RUP's Entity-Control-Boundary (something I just never did buy into), and Michael Jackson's well respected Problem Frames (a book I could never get into). It's an eclectic mix which shows that Rebecca Wirfs-Brock is not afraid to look beyond her own work and pull the best ideas together to move towards an agile design solution.

When I used to live in Kansas City, I regret that I was too busy working (it was the telecom boom) to get a chance to listen to much blues music. I missed a great opportunity.

Recently, I've been mentoring a team on how to "get" a different kind of blues - Peter Coad's "blue" Description Archetype! Steve Palmer wrote this excellent article on the topic. The same technique appears in Nicola, Mayfield and Abney's Streamlined Object Modeling Chapter 6 Object Inheritance though it has a different name.

Why do patterns like these matter?

Simply put good functional architecture provides better encapsulation, better division of responsibilities and more flexibility. The <<plug-in point>> pattern at the end of the Palmer article is a particularly powerful one which provides solutions to carrier class code maintenance and evolution issues.

Agility is about more than just working practices. Agility is at least a 3 sided problem of working practices, architecture and tools. Agile methods which ignore architecture leave future profits on the table. Agile managers concerned with better business performance need to look beyond working practices and insure that their teams are learning and using best-of-breed analysis and architecture methods and using tools which best facilitate the flow of value through their system of software engineering.

[Update on the OMG's Business Modeling RFP - My moles in the know tell me that the Coad, Nicola, Mayfield, Palmer et al Archetype and Pattern Player methods are getting strongly represented. This means that my desire to see Ronald Ross' Business Rules Approach merged with Coad's domain modeling approach has a chance of happening and becoming an industry standard.]

Well not quite yet! But this is good news - I think. OTOH, knowing how slow the OMG has gotten in recent years, maybe not.

No! It is definitely good news. The more mainstream the notion of separate business rules gets, the better it must be for software development.

More interesting is the forthcoming Business Modeling RFP...

The major focus of the Nashville meeting, which was continued at the London meeting of the OMG later in November, was on the Business Modeling RFP.  Discussion about business modeling had started at the September OMG meeting in Boston.  Development of the paper on Architecture of Business Modeling is proceeding, to scope out coordinated RFPs that will together provide robust standard metamodel for business modeling.  So that we are on the same page about what is meant by 'business modeling' in this context, below is the working definition being used by the OMG Business Rules SIG and Business Enterprise Integration Domain Task Force, who is the issuer of the RFPs drafted by the BR SIG.

and I really like the definition of a Business Process...

business process  category of business model that focuses on the transformative aspect of the business -- that is, value chains or sequences of functions that take raw materials or other resources and transform them in such a way to add value for people inside and/or outside the business.

My work with Peter Coad's color modeling with Archetypes [see Chapter 1 of Java Modeling PDF] has given a deep insight into business modeling. I have argued that chains of Peter's <<Moment-Interval>> archetypes represent business processes and the definition from the OMG seems to reflect that - which is good. I first presented the Coad technique at an OMG meeting in Orlando in 2000. [This is the same presentation [PPT] that I gave at the Sprint Object Oriented User Group Conferences in Dallas, Kansas City and Reston in the same year]. There wasn't much of an audience for it then though those who came to the presentation were excited about it.

I really hope that my friends at Borland are making an effort to get the work of Coad, Nicola, Mayfield and Palmer into the mix. I would really like to see Coad's Business Archetypes become part of the standard and color modeling develop a wider audience.