Monday, October 20, 2003

Attending ForUse2003

I’m attending ForUse2003 in Portsmouth, New Hampshire. The coolest thing about this is that I get to meet luminaries like Larry Constantine and Ivar Jacobson. I was fascinated to learn last night that Jacobson agrees with my conclusion from last Thursday - that the OO paradigm has really reached the end of its usefulness. Ivar’s focus is on Aspect Oriented Programming. He has some other fields of interest and was showing an interest in Agile Management and what I’ve been doing.

Some other notable attendees include Ron Jeffries (of XP fame) and Tom Poppendieck, co author of Lean Software Development.

Both Ivar and Larry have promised to take a look at my book. I wonder what they will think?...

Scaling XP to Large Projects

Ron Crocker works as a Fellow of the Technical Staff with Motorola where he helps to organize large development programs for telephony equipment and mobile phones. He is also an agile enthusiast. He’s been developing methods of scaling agile methods to large scale problems by introducing architecture early in the process and separating out concerns into layers on a stack. In some respects this is similar to FDD but Ron is taking it even further. He has a book coming out soon, Large Scale Agile Software Development. To get an idea of what he’s talking about take a look at these slides on his Grizzly method from September 2002.

Sunday, October 19, 2003

Agile Management Introduction

Over the next 18 weeks, I am going to summarize Agile Management for Software Engineering, in a series of twice weekly blog entries - one entry for each chapter. I’d like to start today, with a summary of the Foreword and the Introduction. For those who have skipped to Chapter 1, it really is worth going back and reading the front matter.

The Foreword was written by Eli Schragenheim who co-authored “Necessary but not Sufficient” - the most recent Theory of Constraints novel about the supply chain management solution for TOC. Eli is a software guy, an accountant and a long time expert in TOC as he explains. He lists the two key benefits of TOC thinking as: vastly improving the flow of products to market; and the marketing problem of determining the real value of a product or feature to an end consumer. He rightly observes that my book focuses mostly on the first of these two. Only one chapter - Chapter 16 - Agile Product Management, address the second.

The Introduction sets the scene for why the book is necessary and what benefits it delivers for the reader. It discusses the recent trend in the economy and the trend to outsource software development to locations where the labor is much cheaper. If jobs are to be retained in the expensive West then software development organizations need to improve their competitiveness. It introduces the basis for agile management techniques as a hands-off, highly delegated style, using metrics to transparently report the progress of an empowered workforce. It discusses the advantages found in other industries from changing working practices rather than introducing technology based solutions. The agile revolution is categorized as a rebellion against bad management and a passionate push for a “better way” to deliver software. Finally, it offers the suggestion that perhaps their is a latent economic miracle waiting to be unleashed. What if software development today is as effective as the auto-industry in 1911? There is a potential for a 20 fold improvement (or put another way - 95% efficiency gains). If agile methods allow us to unleash even a fraction of this potential what would it mean for you, your job and the prospects for your employer?

Friday, October 17, 2003

When to Outsource

We had a quarterly all hands meeting at my office today. It was a GM and below level meeting. At the end during the question session, a relatively new employee, a Russian immigrant with improving English, bravely asked, “What about outsourcing - are we going to get it?” (sic) Yeah, you go guy! Stick that outsourcing to us baby!

Our GM deferred the question to my immediate boss, who indicated he was going to delegate it on to me, then he suddenly decided to answer it himself. To my dumbfoundment he then uttered one of the most profound statements I’ve heard on the topic. So good in fact that I quote it for you now - only slightly paraphrased.

We will outsource when there is no knowledge associated with an activity, such as repetitive execution of test plans. We will not outsource where there is knowledge to be gained and retained such as writing test scripts or programming automated tests. We will also outsource when we have resource issues. We will look at each case in turn. When it makes commercial sense we will outsource to elevate a bottleneck.

It’s a textbook answer. It combines Donald Reinertsen’s information theory ideas - in this case, the knowledge to be gained - with the Theory of Constraints and Throughput Accounting -  the bottleneck and the commercial sense - which suggest that investment should be focused on constraints. When there is a temporary bottleneck, a temporary investment is needed to alleviate it. That’s when outsourcing makes sense.

When to outsource is discussed in “Agile Management…” in Chapter 13 Staffing Decisions.

Thursday, October 16, 2003

Business Rules, Object Modeling and FDD

I promised to publish more about The Business Rules Approach by Ronald Ross after I’d read more of it. I also want to relate it to Streamlined Object Modeling, by Nicola, Mayfield and Abney. The latter, shows how to apply business rules into an object-oriented design in a systematic way. So it seemed likely that the two methods were compatible. I have now read both of these books and I believe that there is a benefit in combining the techniques.

Let me save you some effort. The meet of The Business Rules Approach is in Sections 2 and 3. Ignore Section 1 - I found it, boring and wasteful of my time. How to write requirements as business rules is described in chapters 8 & 9 and these are the key chapters.

As I mentioned in earlier posts, The Business Rules Approach divides the requirements space up into 3 areas: Facts (and the Fact Model); Business Rules; and (User) Tasks (though Ross calls them Processes). Let me talk about these in turn.

Facts

Facts and their close cousins Terms describe the domain of a problem. Ross (the author) introduces a new notation for Fact modeling. He did this to avoid confusion with data modeling. Terms are either entities in a domain or attributes of those entities. Facts are relationships between Terms. In addition there are Derived Terms and Calculated Terms - these are also referred to as Functions.

Translation

What FDD calls a Domain Model - Ross calls a Fact Model
What FDD calls a Domain Object - Ross calls a Term
What FDD calls a Feature - Ross calls a Derived Term or a Calculated Term
What FDD calls as Association (on the Domain Model) - Ross calls a Fact

Advantage of Facts

The Fact Model (Domain Model) has a very low variance and changes little -  it is after all based on facts. Regardless of changing requirements in a domain, the Fact Model will suffer very little need for refactoring.

Business Rules

Business Rules describe (primarily) constraints on Facts. [There is that word constraint again].
Such as “A Customer with a Checking Account must also have a Savings Account”

Translation

Business Rules have no direct translation in FDD. We typically write them as notes to Features or simply embed them in Use Cases and cross-reference from the Feature definition.

Advantage of Business Rules

The Streamlined Object Modeling book dedicates a whole chapter (Chapter 4) to Business Rules. It explains how to map them on to a Pattern-Player model (Domain Model - similar to a Domain Neutral Component model using color Archetypes). The advice in this chapter can be mapped directly onto a Domain Model in FDD.

Nevertheless, Nicola and Mayfield observe that business rules are subject to change more often and have a greater uncertainty attached to them. So finding a method of reliably implementing them in code is a bonus.

Ross goes further. He wants them implemented in separate code. His suggestion is that business rules are encapsulated on their own.

It makes sense to separate out business rules during the requirements because they have real business value and are definitely client-valued functionality. This fits with the spirit of “tracking the flow of value”. They are also subject to greater uncertainty and as Donald Reinertsen pointed out in Managing the Design Factory, systems should be partitioned architecturally to decouple uncertainty. It makes further sense to list business rules because Nicola and Mayfield have shown how to map them directly to code. This allows the requirements to be directly mapped to working code which facilitates end-to-end traceability.

Hence, it would seem to be advantageous to build a list of Features and a list of Business Rules in a Value-Driven software engineering method such as FDD.

Process / (User) Tasks

Ross describes Processes but he really ought to call these Tasks or even User Tasks as they describe flows of interaction mainly with the user.

Translation

These are not Use Cases. They don’t have business rules or facts and terms embedded into them. They are more like what Larry Constantine used to call “Essential Use Cases” and later renamed “Task Cases”. Ross’ processes are more like screen flows. They could be represented in a Visual Vocabulary diagram or a UML Statechart.

Advantage of Tasks

The advantage of capturing tasks separately - as my employer does with VV diagrams and I have shown with Statecharts  - is that they can vary independently of business rules and the much more stable fact model. In fact, almost everyone recognizes that UI designers reserve the right to make changes almost right until the end of a project. Bottom line - tasks change often!

Conclusions

The Business Rules Approach offers us the possibility of a new lightweight method of requirements definition which is better able to cope with change and separates out concerns more efficiently - unlike use cases which couple concerns. Ross refers to techniques such as Use Cases generically as “procedural methods of requirements definition”.

The Fact Model - Business Rules - Tasks separation offers us a cleaner mapping between requirements and code. One Term is one Domain Class or ERD Entity or an attribute of a class or entity. One Fact is one association on the model. One Derived (or Calculated) Term is one Feature in FDD. One Business Rule is one Business Rule in Streamlined Object Modeling. One Task is one VV diagram for several Views and Controllers/Actions which are UI Features in FDD.

My biggest conclusion is that The Business Rules Approach threatens to create a paradigm shift - a discontinuity. What it really highlights is that the encapsulation in object-oriented technologies is misguided and of limited real use. It hints at the fact that we need a new paradigm with rules and tasks encapsulated separately. I believe that this gives the Object Role Modeling (ORM) community with authors such as Terry Halpin and David C. Hay a real opportunity to cross the chasm into widespread adoption. It also hints that technologies from Microsoft that are influenced by ORM (MS has never really been an OO shop) may provide a time-to-market advantage over traditional OO technologies like Java. The point being that a system which architecturally partitions uncertainty will lead to faster development and faster subsequent incremental iterations.

Necessary Reading

For those with an interest in this, I would recommend…
The Business Rules Approach  - Section 2 and Section 3
Streamlined Object Modeling  - Chapters 1 thru 4