My daughter has returned yesterday from a trip abroad, and brought me a present - since she knows that I have a collection of teas, she brought me another tea, unfortunately she does not really understand much in teas, so what I got as a present is a laxative tea. Well - I thanked her, and wish that I'll not have the need to use it ever.
entitled "complexity scorecard", the direction of defining indications for complexity is useful, however, this can be taken a step further, since the different indications belong to various topics, some of them about the complexity of functionality, and some on different measurements of scale, high availability and interface type, which are orthogonal issues. The assumption in Mark's scorecard is that if one has enough indications that it is cost-effective to use COTS for event processing instead of hand-code it, however, in some cases it is not the aggregation, since some of these indications can justify COTS even if most others don't exist (e.g. complex functionality), and sometimes the boundaries are not that clear, thus, there is a need to further refine the question "when is it cost-effective to use COTS" ? - thus, while the thinking is in the right direction, a scorecard like this looks somewhat simplistic. Do I have a better one ? -- not really, but will join the chase after it... more - later.
