*Now* How Much Would You Pay For This Code?

Via Larkware and InfoQ, I discovered a great post on code reuse by Dennis Forbes: Internal Code Reuse Considered Dangerous. I’ve written about reuse before, albeit in the context of services. But where I wrote about the impact of context on reuse (high context == low or no reuse), Dennis focused on the idea of accidental reuse. Here’s the money quote from Dennis:

Code reuse doesn’t happen by accident, or as an incidental – reusable code is designed and developed to be generalized reusable code. Code reuse as a by-product of project development, usually the way organizations attempt to pursue it, is almost always detrimental to both the project and anyone tasked with reusing the code in the future. [Emphasis in original]

I’ve seen many initiatives of varying “officialness” to identify and produce reusable code assets over the years, both inside and outside Microsoft. Dennis’ point that code has to be specifically designed to be reusable is right on the money. Accidental code (or service) reuse just doesn’t happen. Dennis goes so far as to describe such efforts as “almost always detrimental to both the project and anyone tasked with reusing the code in the future”.

One of the more recent code reuse efforts I’ve seen went so far as to identify a reusable asset lifecycle model. While it was fairly detailed at the lifecycle steps that came after said asset came into existence, it was maddeningly vague as to how these reusable assets got built in the first place. The lifecycle said that a reusable asset “comes into existence during the planning phases”. That’s EA-speak for “and then a miracle happens”.

Obviously, the hard part about reusable assets is designing and building them in the first place. So the fact that they skimped on this part of the lifecycle made it very clear they had no chance of success with the project. I shot back the following questions, but never got a response. If you are attempting such a reuse effort, I’d strongly advise answering these questions first:

  • How does a project know a given asset is reusable?
  • How does a project design a given asset to be reusable?
  • How do you incent (incentivize?) a project to invest the extra resources (time, people, money) in takes to generalize an asset to be reusable?

And to steal one from Dennis:

  • What, realistically, would competitors and new entrants in the field offer for a given reusable asset?

Carl Lewis wonders Is your code worthless? As a reusable asset, probably yes.

Comments:

It's unfortunate that no one answered your questions, Harry. if they ever do, let me know. I do thing that the stuff you saw was useful and necessary. Just, as you point out, probably incomplete. My personal opinion is that we are serious about code reuse, we need to identify the services that SHOULD be provided by that reusable code. The .Net framework takes the horizontal approach, and tries to fill in gaps for a dozen different types of projects for any business need. If we want to do something in IT, it needs to take the opposite approach: build for one or two project types for one or two business needs, but cross all the way up across the stack. That's right: Components at every level of the stack. Perhaps something for patterns that connect dynamic user interfaces down through the stacks, including workflow and business rules engine, and through to adapters that save data? See what I mean?
i for once think there is no code reusable by default, its much harder to write that kind of code and really what for? because you hope it might get reused in the future? how much reusable code you wrote and .... Its slow you down, i personally know right away if the code should be reusable, if i write something that im planning(90% of time i wrong about it anyway ;) to use in the future then i make it reusable, if i not then i wont. I just wonder how many people really reuse the code? and i dont mean classes that names are ended with Util or Helper.