On A - multiplying bugs. I agree this is a problem, but given a (false) choice to do nothing for reuse, and allow branch and merge open slather I’d opt for the latter. Whether it’s reuse with no maintainer, or striking out on your own to reproduce the mistakes of the past, you’re in a similar situation. The best solution is a good fast central component with versionable interfaces and … [insert your own reuse nirvana here]

On B - Yes, and this list of problem will occur in a variety of reuse strategies.

On C - money quote:

Frankly, I don’t see affordable code reuse happening across projects within big companies until developers are helped and encouraged to update their code for other developers within the same company.

I agree. Any project manager worth their salt utters the words “eliminate dependencies” meaning - eliminate dependence on things I can’t control. Actually, I’d expand that to things that aren’t predictable. Companies need to make reuse as deterministic as possible, and that means commitment to support internal users, and not just your widget manufacturing application that you originally wrote that library for. Without that assurance, open slather, searchability and the kindness of strangers is all ya got.

The problems I see with the fork-and-paste style of code reuse are that: a) telling all the users of a particular class that they’ve got a serious bug, and that they need to upgrade/merge, b) writing code that depends on brittle libraries, c) terrible support for class versioning in most languages.

a) is caused precisely by the no-holds-barred approach to reuse: I can and will copy whatever I can lay my handds on, only to find that you’ve let a security flaw through, and that flaw has infected my code too. Unless I carefully isolate the rest of my app from your library, I could be in for an even more serious flaw in my own application. If your code has been abandoned (as is often the case with Sourceforge, and even some Apache projects), then I won’t even know there was an issue. Resolving the ability to contact me when you discover the problem requires some kind of notification infrastructure, perhaps with an automatic subscription as soon as I download the code.

b) is caused by the number one imperative of a commercial software company: to make money from a product/solution/box/cd as soon as possible, for as long as possible. The developers in the company are strongly encouraged to make their designs as simple as possible, yet still flexible, but only for the domain they’re writing their application for. After all, they’re not expecting their technician’s desktop tool code to wind up in an end user’s core business application.

If the developers of the core business application are careful, they’ll unit test, and functional test the reused code just as if they’d written it themselves, but it’s more likely they’ll just expect it to work, just like we currently do for an Operation System, a programming language’s built in APIs, and so on (well mostly, anyway: the Java Bug Database makes it clear that a long history of use doesn’t make even the simplest APIs defect free).

If the core business app developers are even more careful, they’ll budget time to fix some number of defects in the reused code, ensuring that their changes filter back to the original developers (if they’re still around, or care). However, the more predicatable scenario is a cost and schedule overrun while the team scramble to shore up the foundations of their application, or even delivery of an almost correct (ie deeply flawed) release.

c) is caused by the simplest form of reuse you’re likely to see: I keep the same namespace/package for the reused code, but I patch in a change to the code. You also make a change to the reused code (hell, it’s probably ‘your’ code in the first place). Yet another person tries to reuse your code and mine, and they run into the source-level version of DLL hell. They’re now stuck with the task of migrating my code to the new version of yours, with the possibility that I can then change mine further without accepting their or your changes to your code into my sourcebase. This would mean that they’d have still further work to do to support the two systems, even though reuse is supposed to have avoided this whole problem. An excellent example of how badly this can go is how Java rolled the Xerces XML parser into the standard libraries, leaving users of more modern versions of Xerces with no easy migration strategy.

Languages like Ruby are an improvement in this area, as it’s RubyGems package management system (interesting. Packaging for reuse, eh? Fancy that…) can allow different versions of the same component to be loaded at the same time. Unless you’ve done some amazing magic with class loaders, you’re going to have a lot of trouble doing anything similar in Java. A Servlet container like Tomcat’s classloader heirarchy is a good example of the sort of magic that’s required, and even that has issues (eg, see http://www.qos.ch/logging/thinkAgain.jsp).

Frankly, I don’t see affordable code reuse happening across projects within big companies until developers are helped and encouraged to update their code for other developers within the same company. Software that’s lost all of its developers (thanks to the low, low average stay for a developer at any one job, and management’s fine habit of moving people away from maintenance of ‘finished’ products as far and as fast as they can) should not be relied upon for building reliable systems. Open source software that isn’t changing isn’t good for long term use (9 out of 10 dentists agree with me, so it must be true), and the same is true for commercial software.

You need coordinated development of libraries and applications built with them. You need mechanisms for running two versions of the same library side-by-side. You need real component software.

[BTW, despite the hype behind oh so many tools, I don't think the world has yet had a component oriented system (as if you hadn't guessed). We've had some component-like systems (SOA is in this category, as do EJBs, Servlet Warfiles, Active X and friends, OpenDoc), and systems that claimed to be component-capable (Hi, CORBA, I'm talking about you!), but they're as fun to use as C is when it comes to object programming: you *could* develop C libraries using objects, but it requires creating your own private world of calling conventions, naming guidelines, and a vast deal of paper to paper over the cracks between this and the standard C programming idioms. Don't even try and use your C objects with someone else's C objects.

Believe it or not, Microsoft's .NET is the closest to a component-oriented system that I've seen. However, there's much more that needs to improve before we'll be in a component-oriented world.]

In line with your last point — I think the majority of reuse is not explicitly recognised. When you write Java or C or C++ you’re reusing a library codebase, and the code generated is reused. When you run on an operating system, you’re reusing a substantial codebase. When you develop within a development environment you’re reusing software. When you target web browsers you’re reusing code. These forms of reuse are taken for granted. I think the concern of most organizations is to ensure that their own beautiful code is reused.

I think that code reuse is generally thought of as a problem that needs solving. I think code reuse needs to be thought of as one many methods of increasing productivity, and one that has the potential to decrease productivity if applied injudiciously.

The story for Perl is even better. It’s almost simpler to find a CPAN module than it is to find a book on Amazon, because with Amazon, you have to start a browser first. Maybe NASA hasn’t heard of Perl.

All this goes to support the mechanism you describe: the code is findable, so developers find it. I find it interesting, though, that the majority of successful reuse is not reuse of domain models or business functions, but rather with libraries of generic functionality, frameworks and interfaces to the real world.