Tuesday, February 27, 2007

Exporing Real Option-based Software Engineering

I’d like to follow up my post on why we aren’t ready for real option analysis based decision making in software engineering with an example. As a basis I’d like to use Stephen Palmer’s excellent article on modeling a library management application originally posted on The Coad Letter. If we look at the model (based on Peter Coad’s Domain Neutral Component pattern) we can see that it decouples and encapsulates many concepts.

Fig 1. Model of a Library Management Application (courtesy Stephen R. Palmer)

In his article, Stephen Palmer explores the requirements space and gradually narrows the possibilities and reduces options in the scope. As he does this, he removes classes from the domain model. This demonstrates the “modeling by taking away” approach of  The Coad Method in its final 1999 version using colour archetypes and the DNC pattern. There are many options, for example, the AccountInApplication class decouples MembershipAccount from its role in a Registration. Do we need this class? What does it buy us? If we create this class what “option” is it buying us? We could say the same for the other (yellow) role classes, Library and Member. If we create role classes for Parties, Places or Things, what “option” does that buy us?

Roles classes decouple behavior associated with the transactional (pink) Moments or Intervals of time from the (green) Party, Place or Thing classes. With roles the model is more loosely coupled and more highly cohesive. The (green) PPT  classes are more reusable and their responsibilities are more cohesive. If the (green) PPT class might be involved in another transactional (pink) Moment-Interval or even a whole other application then the (green) PPT class is not polluted with behavior associated with several applications on transactions. This makes the classes cleaner, simpler, of higher internal quality and probably easier to test, resulting in better external quality. But there is an even more useful purpose to separating out (yellow) role classes from (green) PPT. It allows postponement of component boundaries and separation of code into discreet coarse-grained components, packages or applications. I explained this in a later Coad Letter article.

So the real option theory question becomes a trade between the cost of creating the (yellow) role class - the price of the option - and the likelihood that (green) PPT will be involved in another (pink) Moment-Interval and that there will be a desire to separate out the different transactional application pieces from the reusable (green) PPT and (blue) Description classes. The likelihood will depend on the domain, the specific requirements and the direction of the business in future. As I described last week, assessing the cost of building the extra (yellow) role class is almost impossible, and assessing the probability of the need to decouple transactional behavior and/or partition in to discreet components is equally hard. Hence, the input data for the real option equation would be highly suspect at best.

Let us analyze another example using the same model from Figure 1. The (blue) Account Description class allows us to separate out meta-data describing types of accounts and associated behavior. For example, the maximum number of books that can be borrowed by any member registered with this type of account. Description classes are often implemented as database tables or as XML files that are loaded dynamically. Both approaches allow for the meta-data to be updated at runtime. In Lean terms, for the description definitions to be postponed until runtime. Building a (blue) description class using a table-driven or XML file-driven approach is buying an option to postpone description definition until runtime. To assess this option, we must again be able to account for the cost of building the table access or the dynamic XML file loading infrastructure. We must also be able to make an assessment of the likelihood that the description definitions will change and how often this is likely and with how much notice. Is it likely to happen more often and with sufficiently short notice that deploying a new version of the software would be undesirable? Would we prefer to have a system administrator or a “super” user update the definitions rather than involve the programming and testing team? If we can assess both the cost of buying the option and the likelihood of the option being exercised then we can use real option analysis to make a decision about the value of building the (blue) description class, and whether it would be better to build a table-driven implementation or an XML file-driven implementation.

If your organization is capable of making these kind of well informed, real option-based architectural and design decisions, please write to me or leave a comment. Equally, if you think we are years from having that kind of maturity, I’d like to hear from you too. Technorati tag: Agile, David+Anderson, Real+Option+Analysis,  Software+Engineering, Stephen+Palmer

Making Progress with Imperfect Information

I’ve been reevaluating my view on refactoring!

It’s interesting how your viewpoint can color your view of something. My viewpoint in to the agile community and its practices has always been rooted in my experience with FDD/The Coad Method. When I spoke at USC back in 2004, I suggested that though FDD may never be seen as the most agile of Agile methods, it was probably the most Lean. I stand by this comment three years later. FDD is very Lean. All the waste is trimmed out. The Coad Method techniques deliver a very precise definition of a domain, that is loosely coupled and highly cohesive, while the Feature definition technique delivers fine-grained customer-valued units of work that exhibit very low degrees of variation. The batching technique of Chief Programmer Work Packages is very efficient and minimizes transaction costs associated with work-in-process. I could go on, but you get the point that FDD is Lean. The modeling, planning and batching for design and build result in almost no need to refactor code on FDD projects. As a result, my book classified refactoring as rework and labeled it as waste.

From my FDD viewpoint that might have been a fair assessment. However, now that I’m running a software engineering organization where I inherited a waterfall process, that runs through a series of narrow and specialized departments such as Business Analysis, Systems Analysis, Development and Test, I’ve changed my opinion. From a new viewpoint refactoring is clearly a very valuable process.

I believe that Alistair Cockburn’s paper from the ICAM 2005 International Conference on Agility will come to seen as a seminal paper in Lean Software Engineering (ironic as it was inspired by the Theory of Constraints). In this paper, Cockburn explains that asking a non-bottleneck resource to do extra work to rework something does not cost anything extra and can create a desirable effect because it allows progress to be made and demonstrated earlier. Ergo, rework is not waste when performed by a non-bottleneck resource.

There have been many versions of the idea that perfect is the enemy of good enough. The original is attributed to Voltaire. And it is this concept that refactoring (and Cockburn’s paper) embrace. It is argued that it is better to make progress with imperfect information and refactor later when better information is available than to wait for better information before progressing.

Specifically, I am thinking that it is better for developers to start coding with imperfect analysis than to wait for a systems analyst to produce a “perfect” specification. The developer can then refactor the developed code when the analyst makes a final version of the specification available. My reasoning is simple. The developer would otherwise be idle. [Not truly idle, there is plenty of busy work available, grooming environments, training on new languages and APIs and so forth but idle in the sense that they are not adding value to the deliverable.] By definition a resource (or station) with idle time is a not a bottleneck resource. It is, therefore, OK to ask the developer to perform the refactoring. The refactoring cannot be classified as waste in this case.

We can think about this decision using real option analysis. The option we are buying is to deliver the working code earlier. The cost of the option is the cost of having the developer start work before a final specification is ready. The risk (or uncertainty) attached to the option is the risk that the early imperfect specification will be significantly different from the final specification and that any rework will take longer than waiting to start coding on delivery of the final specification. Note that the rework may absorb all of the slack in the non-bottleneck resource turning it in to a bottleneck and delaying the whole project. This gives us a framework to decide whether starting early and refactoring is the correct decision, or whether waiting and coding for “right first time” is the correct decision.

[It would nice if someone reading this and perhaps actively studying for a masters or doctorate in the field were to develop this concept and publish it complete with equations and data from sample projects. ] Technorati tag: Agile, David+Anderson, Real+Option+Analysis, FDD, Coad+Method, Theory+Constraints, Lean, Software+Engineering, Refactoring