Analysis: don’t make things artificially different

In any order management systems a quote is not quite different of an order, just a different status of the same entity that is the description of a work to be done (status = POTENTIAL) or done (status = COMPLETED). However I usually find people are tempted to consider they are different concept with no link between them except some similar fields. As if it was easier to consider them different… I don’t think so.

The easiest way to be lazy is simply to write one thing instead of writing two things. Making quote and order two subclasses of the same abstract class is easier, and still enable to use quote-dependent or order-dependent behaviour (i-e methods).

To go further on this idea, and to be more lazy, one can also add virtual capabilities to a concept just to consider it the same as another concept:

• using the Composite pattern, to make no difference between a whole and a part
• thinking about things as special-case of other things, e-g a financial Index can be considered as an Instrument even if it is not really tradeable, only for convenience: it can be used as an underlying for derivatives in the same fashion, there is no point to consider it different unless we really need to.

A common way to forget about what things really are and use them as only one common thing is to think of their common business capability, i-e the common use a specific interface: Sellable, Tradeable, Priceable, Product (as something that can be described, quoted and sold)…

Also, sometimes there is even no need to be accurate when some processing does not actually care what things really are, which happens surprinsingly often. In these cases you’d better just use general Java supertypes: Object, Comparable, Serializable… You’ll gain higher reuse and cleaner code.

One last note about the project management point of view: the differences that do matter to split a project into subparts (to allocate work for small teams for instance) are not always the most obvious. Consider a project in an asset management house that deals with several kinds of financial instruments, say Stocks, Bonds, and Derivatives; many project managers will be tempted to split the project into a Stock subproject, a Bond subproject and another Derivatives subproject.

This is a fatal mistake, since from the asset management point of view the difference between all these kinds of instrument is really small. In this case it is very likely to have complete duplication of the code in each project, just because things have been made artificially different. In short, do not split project scope at random, most obvious classifications are, by definition (because a classification is already a successful attempt to extract commonalities), NOT good candidates to split the workload !

Initially published on Jroller on Thursday April 07, 2005