Thursday, August 26, 2004

Whole Part Relationships

The second of the teasers for my forthcoming paper at Borcon on Advanced Domain Modeling is titled “Whole Part Relationships in Color Modeling” and is intended to cover some material poorly dealt with in the original color modeling book. Once again this one seems to be getting very mixed ratings. The introduction gives a flavor of what’s covered…

Introduction

Peter Coad first introduced us to color modeling in The Coad Letter #44 back in 1997. Since then there have been many updates from Peter and later Stephen Palmer. However, Java Modeling in Color [Coad 1999] the book which formally introduced the topic left many questions unanswered. Since, then some of these questions have been addressed in a number of Coad Letters. One area which still remains unexplained is the use of Whole-Part relationships in the Domain Neutral Component (DNC) [Figure 1]. The DNC had only one Whole-Part relationship, the aggregation of <>s into <>s. However, practical color models do feature both composition and aggregation in other places and modelers are often left wondering, what is the “right way” to model these relationships and which colors should be used for the diagram. Does a pink class always aggregate a pink class? Does a green class always aggregate a green class? Is it the same for blue classes? These are questions I get asked often when facilitating modeling sessions. This article seeks to demystify aggregation and composition in color modeling. It pools heavily from the lessons in Streamlined Object Modeling [Nicola 2002].

[Download “Whole Part Relationships in Color Modeling” in PDF]

Wednesday, August 25, 2004

Coloring with Demeter

I wrote 3 Coad Letter articles intended as teasers for my forthcoming paper at Borcon on Advanced Domain Modeling. The first of these is titled “Color Modeling and the Law of Demeter” published at The Coad Letter on August 13th. It seems to be getting incredibly mixed reviews. Here’s the introduction…

Introduction

One of the most widely misunderstood elements of color modeling and the Domain Neutral Component is its loosely coupled nature and the use of what is often referred to as the Law of Demeter. In a DNC compliant model, it is intended that classes only hold dependencies on their immediate neighbors in the DNC. This reduces the coupling of architecture and allows decisions on the packaging and coarse-grained componentization to be postponed until much later. The DNC treats every class as a component and both its interface and degree of coupling are carefully considered.

[Download “Color Modeling and the Law of Demeter” in PDF]

Tuesday, August 24, 2004

Happy Birthday!!!

This blog is one year old today. I started it as a way of publicizing my book. I can’t be more pleased with the results. The book has outsold my expectations for it and has been very well received. Now, in summer 2004, it seems widely accepted in the agile community that the Theory of Constraints has a role to play in the software engineering process. One year ago, that really wasn’t true. Putting the book aside though, this blog has been very successful too. During the year I have posted 205 blog entries (including this one) and 15 other articles. Perhaps it is the content which keeps people coming back. With around 500 page views per day and over 10,000 RSS feeds per week, I’m amazed at how the audience has grown. Thanks - it makes it all worthwhile to know that people actually read the material. Most curious has to be the popularity of the overview slides. These receive around 100 downloads per day. I’d love to know why…

Saturday, August 14, 2004

TOC Software

Clarke Ching has started a Yahoo! group and weblog for virtual team to work together collaboratively to apply the TOC Thinking Processes to the problems in software project management. This isn’t your usual kind of group chat or publishing weblog, it’s real interactive work with a specific goal in mind. Learn more at TOC Software.

Tuesday, August 10, 2004

Drucker on Refactoring

Drucker on Refactoring - no really! Here is what Peter Drucker might have had to say about refactoring were it available as a practice when he wrote these words in 1954.

“A favorite story at management meetings is that of the three stonecutters who were asked what they were doing. The first replied, ‘I am making a living.’ The second kept on hammering while he said, ‘I am doing the best job of stonecutting in the entire country.’ The third one looked up with a visionary gleam in his eyes and said, ‘I am building a cathedral.’

The third man is, of course, the true ‘manager.’ The first man knows what he wants to get out of the work and manages to do so. He is likely to give a “fair day’s work for a fair day’s pay.”

It is the second man who is a problem. Workmanship is essential; without it no business can flourish; in fact, an organization becomes demoralized if it does not demand of its members the most scrupulous workmanship they are capable of. But there is always a danger that the true workman, the true professional, will believe that he is accomplishing something when in effect he is just polishing stones or collecting footnotes. Workmanship must be encouraged in the business enterprise. But it must always be related to the needs of the whole.

... The tendency to make the craft or function an end in itself [in future] will therefore be even more marked than it is today. ... The new technology will need both the drive for excellence in workmanship and the consistent direction of managers at all levels toward the common goal.”

What Drucker is telling us is that craft workmanship such as zealous refactoring is important both to an organization’s morale - it is important that people can take pride in their work - but also to the quality of what is being produced. However, over-zealous refactoring destroys shareholder value. So beware of the cruft polisher on your team. Refactoring should be done for the right reasons - to eliminate technical debt, to rebalance the books, and facilitate future iterations. It should never be done simply because a developer doesn’t like the architecture or the implementation. If you can’t answer in the positive to this question - does this code prevent us from efficacious delivery of future functionality? - then any refactoring is to use Drucker’s term merely “polishing stones.”