Tuesday, August 31, 2004

Quality is Defined by Customer Value

Quality is defined by the value a customer derives from a product or service. It is not defined by conformance to specification. Last night I learned this lesson as I rejected my new car - for which I have waited 60 days - and left it lying in the dealer lot. The problem wasn’t a clunky gearbox, or an ill fitting door. In fact I never even sat in the car. I didn’t even have the keys in my hand. I could tell from 50 paces away that the car lying in the lot, wasn’t the car that I ordered. Sure it was the right color and the right model but a key factory fitted option - the roof rack bars - was missing. Without these the car wouldn’t serve one of the two purposes for which I was buying it: purpose 1 - commuting; purpose two family vacations and weekend trips in comfort. With a child (or two), a dog, camping gear and several bikes, a roof rack is essential equipment. So the salesman was left to scratch his head and wonder where it went wrong. The sales manager lost an end of month sale to close out his figures for August. And, I was left spending 2 hours of my evening family time, sitting in a dealership, tired and hungry while we tried to sort the mess out and agree what would happen next. Disappointment all round.

What will happen to the car I ordered? Well it will be sold before the week is out. 2 weeks ago the dealers inventory manager told me that he could have sold it five times over. It’s in an unusual but in-demand color and while it showed on their inventory, several other dealerships had asked to swap it as they had customers who wanted one. Meanwhile, I’ll still be commuting by bike and bus across the 520 to Redmond.

Monday, August 30, 2004

Borcon 2004 - Sep 11-15

I’ll be speaking at the Borland Developer Conference in September. I’m giving two papers

• session 2182 - Advanced Domain Modeling: Architecting for Agility with Color Models
• session 2184 - Managing Lean Software Development with Cumulative Flow Diagrams

If your going to be in San Jose that week come see me deliver a 5 year update on color modeling including all the latest thinking from me and Stephen Palmer (author of “A Practical Guide to Feature Driven Development”) and my latest thinking on managing FDD projects using cumulative flow diagrams rather than earned value.

Sunday, August 29, 2004

Microsoft Betas Agile Process

Microsoft is releasing an agile flavor of the forthcoming MSF V4.0. Download a sneak preview from this GotDotNet Workspaces site. [You need a Microsoft Passport to get in and you may need to be logged in to passport before you select the link to be successful].

Saturday, August 28, 2004

On Joining Microsoft…

I recently decided to take a job at Microsoft as a Program Manager. I don’t intend to explain the complex decision that went in to accepting the position. Doubtless there will be some who criticize me for “selling out.” Fair enough! I did negotiate the right to keep publishing this web site and to retain the copyright in the material published here. I think that’s important and I think Microsoft value this site and its independence.

As there will doubtless be questions like “What happened to VA Systems?” I feel I need to say something about that too. Daniel Vacanti and I remain friends - in fact we talk often. Dan still intends to be involved in consulting and teaching teams in North America, both Feature Driven Development and Domain Modeling in Color. The VA Systems web site is still up and the services are still available. The difference is that I’m not part of it.

My first impressions of Microsoft are extremely positive and I’m sure that I’m going to enjoy working there. They are giving me an opportunity to carry on my work in software engineering process and management and to collect a pay check for it. There will almost certainly be another book too. I’m joining the developer tools division working on the future versions of the MSF process within the Visual Studio team. The MSF Agile process just announced is not my work. It was created before I joined the company. I’m looking forward to learning a lot of new things at Microsoft and working with my new colleagues and real .NET developers to push my own work further. You will get to read the results here.

As a result of this switch, I will not be publishing The Coad Letter at the Borland Developer Network any further. Microsoft will be providing me with a new column on one of their web sites. More news of this later.

David

Friday, August 27, 2004

Coarse-grained Components

The third and final of the teasers for my forthcoming paper at Borcon on Advanced Domain Modeling is titled “Coarse Grained Components from a Color Model.” Again its getting very mixed ratings. I wonder why this is? Are the low ratings from people who have no idea what color modeling is all about and haven’t followed Stephen Palmer’s column at The Coad Letter over the years, or are they people who love color modeling and are resistant to change and new material being published? Hmmm….

I personally feel that this article is one of the more important papers I will publish this year (or any year) as it lays the groundwork for how to use domain modeling as the basis for service oriented architecture and it shows how to use a bottom-up domain modeling approach to provide a Lean postponed decision on the selection of components. This reduces change and variation in interface design and makes development run more smoothly.

Introduction

I am often asked, what is the relevance of domain modeling in an age of distributed application frameworks and service-oriented architecture? One answer and a simple one is that there is no replacement for good analysis. Domain modeling in color helps you to understand a problem, analyze it thoroughly and communicate it clearly. It gets everyone on the same page. However, if that were all then you would only ever need a simple drawing tool for models and there would be no need for a sophisticated tool such as Together Control Center which keeps code and models in synch with continuous round-trip engineering.

However, as Tate et al [Tate 2003] demonstrate in Bitter EJB, a good component architecture should have a normalized, domain driven, functional architecture within a set of coarse-grained components whilst exhibiting a service-oriented architecture externally between components. This means that domain modeling in color can be used with application framework development and specifically it can be used to design coarse-grained Beans within an EJB framework.

[Download “Coarse Grained Components from a Color Model” in PDF]