Kirk, Usually the value of reuse is measured in dollars (euros or whatever), not in lines of code saved. The major area of savings tend to be:
- development costs - if you don't have to develop it, it's impact on your development timeline is reduced to the time required to learn how to use it and integrate it into your software. - opportunity costs - if you have to develop/maintain it yourself, your team can't be working on some other high priority task. - maintenance costs - the larger your codebase, the greater the likelihood of bugs and the larger your maintenance costs. I'm not saying that all open source software is bug free, but you have more eyes looking at it, and when you do run into a problem you have the ability to report the problem, fix it yourself, or pay someone else to fix it for you. Most managers are capable of converting hours into money, so the ball's back in his court to generate metrics. :-) Mark On Mon, Oct 13, 2008 at 11:36 PM, kirk <[EMAIL PROTECTED]> wrote: > > 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 > > > > > -- Mark Fortner blog: http://feeds.feedburner.com/jroller/ideafactory --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
