Wednesday, September 14, 2005

 

Kicking reuse in the A$$

I've spent the last two days (and tomorrow as well) over the design of a new product. The whole project has been an exercise in fighting complexity and "featuritism" or, put another way, in shrinking down requirements and technology to a bare minimum. The goal was clear (at least to me :-) : provide the core benefits to the user, avoid any useless and costly feature, squeeze development times by allocating features where they belong.
We obtained a dramatic improvement in development time (and in my opinion, in product marketability) by moving some features from the PC to the embedded side (!). Another big gain came from kicking a standard protocol out and using a tailored command (within the protocol framework, but still entirely custom); this improved reliability as well. The final, substantial gain came from kicking out a large, reusable infrastructure we built years ago for similar applications, and designing a (much smaller) custom solution.
Now, this is not the kind of suggestion people would expect from me. But reuse is not a value per se. It's a value when it provides an economic advantage. In this case, the initial investment needed to fit the problem inside the large, complex architecture just wouldn't pay off. Besides, the custom solution is not badly designed. We have a clear point where we could theoretically sweep out the custom part and plug a bridge to the more powerful infrastructure. This is, in my opinion, quite sensible design. We have the minimum overengineering needed to move to an higher level later, at low cost, if we ever need this. Meanwhile, the project will sell, and hopefully sustain itself.
Economy 101 :-), or a careful use of Real Options theory? More the first than the latter, but again today, when designing a reporting subsystem, there was a clear separation between what is useful to design now (everything down to an XML document), and what is better (economically better) to postpone until a more careful evaluation of alternatives has been carried out. This is easily explained by Real Options - the option to wait on this part has more economic value than the option of designing it straight away. This (as well as kicking code reuse) is somewhat entangled with the notion of Second Order Ignorance from Armour, but I'll leave this as the dreaded exercise for the reader :-))).

Labels: , ,


posted by Carlo.Pescio @ 9:52 PM <permalink>
bookmarking:    
Comments:
Ad essere veramente sincero, se devo fare un poco di retrospettiva su tutte le implementazioni lungimiranti fatte in passato, non sempre è tornato comodo averle pensate per una maggiore espandibilità alias riusabilità. Tante volte ci si lascia prendere la mano e nel timore che ci possa mancare qualcosa sprechiamo inutilmente energie per realizzare cose che raramente verranno utilizzate. Oltretutto trascurando il fatto che chi ci ha commissionato tale oggetto aveva bisogno di molto meno e noi di libera iniziativa ci abbiamo messo del nostro nel tentativo di accontentare anche esigenze future ma per cui non percepiremo più alcunché. Qual é il giusto limite? Keep it simple dovrebbe essere sempre in cima a tutte le direttive. Time is money non necessariamente per guadagarlo, ma soprattutto per non sprecarlo, magari per dedicarlo ad attività più interessanti dell'artigianato del software.

Scusate l'ermetismo post prandiale.
# posted by Anonymous Romano Scuri : 2:14 PM
 
Santin P.:->>
"Economy 101 :-), or a careful use of Real Options theory? "

scusate l'ignoranza...
ma sono dei termini che non mi dicono molto... qualcuno mi da degli hints (i.e. siti) dove possa farmi un 2 idee?
# posted by Anonymous Anonymous : 5:34 PM
 
"101" e' il suffisso tipicamente utilizzato nelle universita' americane per indicare il primo corso su un argomento, quindi di solito i primi anni troverai un "economy 101", "computer science 101", ecc.
Sulle real options, invece, per iniziare potresti leggere:
una buona introduzione, dalla University of Washington Business School: Introduction to Real Options (ebbene si, e' un .doc, qualcuno mi odiera' per questo link :-))).
un articolo, The Structure and Value of Modularity in Software Design, che tenta di introdurre il concetto all'interno dell'attivita' di design.
# posted by Blogger Carlo.Pescio : 9:49 PM
 
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?