A chain of blog posts came through my reader this week that discussed the value, or lack thereof, in "code reuse" for most development teams. First, some background...
It looks like the original article was "Internal Code Reuse Considered Dangerous" by Dennis Forbes (great blog, btw). That article was then referenced by Carl G Lewis (cysquatch), who largely agrees with the sentiment in his "Is Your Code Worthless" post. Finally, Scott Reynolds referenced Carl's blog post in a follow-up the other day, wherein Scott suggests that "Code Reuse Is Not the Villain".
Still with me? Good.
As I worked my way back in time (Dennis' original post is from 2005), it occurred to me that this line of trackbacks is a bit like the "telephone game" that we played as kids. As each person responded to the previous person, the meaning of the story changed in subtle (but important) ways.
In deciphering this, I hope it goes without saying that "code reuse" as a practice is a worthwhile goal to keep in mind. It's not always achievable, nor even desirable, but certainly it's something that good developers keep in mind as they work.
That said, Dennis begins by arguing against the management notion that code reuse saves money by "codifying the abilities of the team" -- thereby making the team easier to replace or downsize. Ouch.
Code in the library is considered an asset, and managers and owners like the idea that, while developing product A, as a side effect they're accumulating this great repository of generalized code which they'll be able to use for a completely different product - let's call it product B. Soon the domain knowledge of their developers won't matter (and thus they'll be expendable), because everything is encapsulated in common code: They've codified the abilities of their team.
I'm not sure how any worthwhile manager could get from Point A (the practice of "accumulating [a] great repository") to that particular Point B (where the "domain knowledge of their developers won't matter"). And in fact, Dennis' rebuttal to this point is that the opposite happens -- the more you grow internal frameworks and libraries, the more you depend on your developers. New developers, regardless of previous experience, have a substantial learning curve in front of them with any of your internal code.
And in that, I completely agree. Where I got lost in Dennis' argument was in the next portion where he appears to argue that code has no value beyond the developers writing it and the project they're writing it for. [emphasis mine]
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.
This is the part that loses me completely, for two reasons:
- It assumes that the value of reusable code is measured by what an external entity would pay for it. I'd argue that it should be measured by its value to the company that owns it. Not just in that it saves time for the team that wrote it... but that it reduces bugs by ensuring that a bug fixed in one location is fixed for all locations. A user interface metaphor or workflow used in one place is used in multiple places. Blah, blah, blah, the usual examples... Reusing code in the correct way increases the value of a product in the eyes of customers and prospects and this has very direct value for the company's bottom line.
- That argument also ignores technology acquisitions. The value of Visio's code when Microsoft bought Shapeware was something (much) greater than $0. It's not as if Microsoft needed the customer base or the market share. Similarly when Google purchased Writely or when Yahoo bought del.icio.us. In each case, the acquisition was a technology purchase -- the acquirer was infinitely larger than the company being bought and wasn't already in competition with them. The purchase wasn't just for the customer list.
I actually think Dennis' point is best made in a bullet point later in the post. And the point is that code reuse merely for the purpose of code reuse is a waste of time and money. [original emphasis]
Internal code reuse for niche industries and domain specific problems can be very valuable, but code for generalized, industry-wide problems are seldom valuable unless you're truly developing it for industry-wide consumption (e.g. the .NET Framework is tremendously valuable code reuse). I have seen too many examples of large internal libraries that are largely duplications of vastly superior functionality existing in the .NET Framework or C++ Standard Template Library, or which could be better served by available professional or open source libraries. If your problem isn't domain or niche specific, but rather is industry wide, it is extremely likely that either a library encompassing it exists, or that it isn't a problem that is worthwhile generalizing
And here's where I'd agree... I, too, have seen many examples where companies simply reinvent the wheel in the name of "reuse". Hey, if it's ours then we can change it, fix it, and reuse it -- right? It's really a buy-versus-build debate. If your team is writing things like data access layers, UI controls, or validation tools in the name of "reuse", then you may as well go out to your parking lot and just light some cash on fire. At least it'd be quicker and you'll get the momentary heat and entertainment.
The above quote is what Carl's response (from last month) is based on... and while the post's title ("Is Your Code Worthless?") is plenty controversial, his purpose was really more to tell a story -- and a funny one at that. It's the story of a client company who felt that their internal code was so proprietary and so valuable that they couldn't possibly let a contractor look at it offsite. Instead, they had Carl travel 8000km to work on it at their location -- only to discover that the code was a complete disaster. What a great line...
I sat down and fired up Vim to start looking at their code and was INSTANTANEOUSLY BLINDED by the reeking bile that was pouring across my monitor.
Hilarious.
Lastly, it's worthwhile, I think, to differentiate between the development of internal business applications and developing commercial products. If you're building internal applications (e.g., payroll, HR, accounting types of systems), then managing reuse across multiple applications is probably not as important. There's still value in reuse for you, but your company doesn't lose customers if the display grid in Application A is different from the display grid in Application B. The tolerance for error is higher. With commercial products, though, it's a different story. It would be silly for the Word, Excel, and Powerpoint teams to all go create their own base UI libraries or text-formatting behavior. And the consequences of a mistake are greater and more easily measured.
I guess the point is to not get carried away with a "reuse is worthless" meme and suggest turning away from it altogether. In 16 years, I've worked on several product lines that made extensive use of shared/common libraries, to great effect and to great value for the company. Bottom line - the key is to pay attention to where building your own libraries for reuse makes sense and where you should simply reuse existing, proven libraries.
In either case, recycle the good stuff... future generations thank you. ;)