I was once sitting at lunch with my supervisor (at a large corporation) when he asked, how can we measure code reuse. My quick response was to ask 3 question; who's bonus was based on getting what number and what cut do I get if I give him that number. As you can imagine the answer wasn't so well received on more than one level. ;-) But we got serious about, ok we've sold this OO sh1t to management and one of the *big big big* benefits was better reuse. Now shame on management that we had to now backup the sales pitch with a real number.
So off I went scowering the literature looking at claims of 50% resue, 80% reuse and in one book I recall seeing a number of 95% reuse!!!! Wow!!! The only problem was, no one backed up their claim with a method of measuring reuse. All it did was fuzzy up the definition of what reuse actually was. So, what counts as reuse. Reusing code (component/framework.. what ever was readily runnable) would seem to be clearly on the table. How about reuse of design? Reuse of features? How do we include components in the number. Just what is the reuse value or weight that should be applied to any of the items that were on our list. We did come to a conclusion. Every class (evenly weighted) borrowed counted as reuse. All classes written by the project team counted against. Add the two values up, turn the crank and wham, exec gets bonus. Perfect until I mentioned we mentioned one small problem. So our supervisor is trying to avoid us at this point but when we finally cornered him I asked, what if, by making things better, the reuse value actually got worse. Not thrilled to discuss he immediately dispatched me to integrate an in-house framework (part of everyone's reuse numbers) work with a new product. As part of the exercise I did a slight code reduction that eliminated about 1/2 of the classes along with more than 1/2 the code (yes, it wasn't written very well to begin with so it's no big deal). Overnight everyone's reuse numbers go worse. Conclusion, all of the *experts* that I read spouted the value of reuse but not one of them cited a way to measure. I came to the conclusion that the whole thing was a ruse in the reuse is really about effort saved. And the only way to measure effort saved was to some how measure both effort spent and effort it would have taken us had we done all of this by ourselves. I am convinced that the output of a business application development team is *not* reusable components and frameworks. It is their responsibility to deliver features that support overall business function. Componantizing code so that others can reuse it take an enormous amount of effort that distracts from the primary function of the application development team. The best frameworks and components IME are those that have been harvested by infrastructure teams out of the business applications. That said, IME, it is almost impossible if not down-right exorbitantly costly to try to extract the supporting code out of a business application. Typically the code is very messy and highly coupled to the point where... well you just don't want to go there ;-) That said, reuse is alive and well and it's all around us. We take adantage of it everyday. Log4J, any JMS product, browsers , all examples of great reuse success stories. Regards, Kirk --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
