Dennis Forbes questions the tendency of many in-house dev teams to spend a lot of time building in-house frameworks and libraries intended for reuse across projects:
The greater the bulk of code you accumulate, the more intrinsically you tie yourself to your current developers (and the more they occupy their brain with information that is only applicable in one organization or team), and the more difficult it will be to bring new developers online. Such frameworks and libraries often come with enormous learning curves for new hires - especially as documentation is virtually always ignored - and they can seldom be reused for anything else without significant refactoring (because they likely weren't truly designed for reuse, or they were in only the most arbitrary and superficial of ways…InfoQ states:
… The question every organization needs to ask itself, then, is what value they could sell their "reusable code" for - what, realistically, would competitors and new entrants in the field offer for it? The answer, in almost every case, is $0, and they wouldn't want it even at that price. There is extraordinarily little code theft in this industry (even though we're in the era of burnable DVDs and USB keys) because most code - above and beyond the industry-wide frameworks and libraries - has no value at all outside of a specific project with a specific group of developers. Trying to use it for other projects is often worse than starting with nothing at all.
Forbes concludes that because properly abstracted and generalized frameworks are more expensive to design and develop than one-off solutions, and since the time and cost for a developer to absorb the complexity of a new framework is rarely taken into account when doing a code reuse cost benefit analysis, it makes sense to reuse code a lot less often than one would think.Though agreeing when talking about general frameworks (and yes, this is still code reuse, it is just not developed and maintained by our organization), there is still space for code reuse over domains that differentiates our organization from the competition. These should be the domains where we should put our efforts, bearing in mind that we should decouple this code the most we can.
And watch out, lets not fall all over again on the NIH syndrome. And above all, please reuse the same frameworks all over your organization! The frameworks don't need to be built in house, but they should be coherent and cohesive. Please don't build your projects over too large palette of frameworks.
2 comments:
I think code reuse inside an organization only makes business and technical sense when:
- it's a solution (that can be reused over multiple projects and solves a business need - for example, a payment solution)
- it's an algorithm (small maybe a function or class) that can be understood easily (compute check digits, alternative rounding, etc)
Everyhing else is hardly reusable, has documentation problems (usage examples, configuration), difficult to maintain, coupled to a technology in time (anyone for a framework in VB6?) and normally too inflexible (even big frameworks suffer from this).
The operational word here is "reusable" ... is custom code really 'reusable' without some sort of intimate knowledge of structure, domain or project requirements, team or programmer rationale and so on.
We should trive for reusable components, services and some sort of higher level artifacts that fits onto our project without the need to completely and fully read and "decypher" the code.
Post a Comment