Mark Fortner wrote: > Kirk, > Usually the value of reuse is measured in dollars (euros or whatever), > not in lines of code saved. that is effort saved, not lines of code. Lines of code is not a very good metric in OO. And yes, $$$ is a reasonable abstraction of time/effort > 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. > yes, that is included in the effort save equation > > * opportunity costs - if you have to develop/maintain it yourself, > your team can't be working on some other high priority task. > again, covered in effort saved > > * 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. > again, effort saved. > > * > > > Most managers are capable of converting hours into money, so the > ball's back in his court to generate metrics. :-) well, in effort save you have to understand effort that would have been spent ;-).. and we know how good we all are estimating that part of the equation ;-)
Kirk > > Mark > > On Mon, Oct 13, 2008 at 11:36 PM, kirk <[EMAIL PROTECTED] > <mailto:[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 -~----------~----~----~----~------~----~------~--~---
