Kevin's Weblog

[This is a modified version of something I blogged at work, somewhat edited to protect the guilty]

There are perennial discussions about how to encourage software reuse, mostly with the unstated assumption that developers are somehow opposed to the idea and need to be convinced to do it. Occasionally, people even suggest that we ought to give bonuses or something similar as incentives.

This seems to be a fairly bad approach to encouraging code reuse. In fact, a fair number of respected people in the software development field (example, example) consider bonuses to be a bad form of incentive in almost all situations. Beyond the question of whether this is an effective way to motivate developers, without a lot of careful thought, a system of directly rewarding the producers of reusable code is bound to create a disfunctional work environment as it destroys alignment between the goals of workers and their immediate supervisors.

My belief is that left to their own devices, the majority of developers want to produce good code which other people will use. There is nothing more depressing than spending a lot of time and effort on a project that no one ever uses. Conversely, just knowing that people are using and appreciating your work is a great incentive (assuming that basic needs like food, shelter, and toys are being met via salary). The obstacles to producing reusable code are almost entirely at the low- and mid-level management level, not at the developer level. This is the group which must be encouraged, through reasonable schedules and vision at the CTO/CIO level, to create the code reuse environment.

The only major exception I see to what I’ve just said is documentation. Most developers don’t like writing documentation and don’t do it well, even if given the time to produce otherwise excellent software. Fortunately, this problem is fairly easily solved by just hiring writers.

The flip side to all this is encouraging people to actually reuse the code which has been produced elsewhere in the company. In my opinion, this is a much bigger problem. Naively, the situation here is reversed in that managers should see reusing components as a solution to their schedule problems, while developers tend to resist for a variety of reasons. More realistically, there is probably resistence at the manager level due to the increased cross-team interaction required in finding and validating appropriate components, and enhancing them if required.

On the developer front, the biggest issues are probably those of knowledge management (finding appropriate components to use) and documentation (finding out how to use an ostensibly useful component). The documentation problem is relatively easy, as I pointed out earlier. Unfortunately, knowledge management is hard. Really hard. A system for cataloging software components has to go well beyond simple keyword searching. It needs to be cognizant of interface, semantics, performance and scalability metrics at a bare minimum. I don’t really know what’s out there at the moment. And, it’s slightly possible that the answer here is actually just as simple as “hire a librarian”. But, I sort of doubt that library science is as evolved in this area as we would need for this to be a routine thing.

We also have to admit that there is the social aspect of developers thinking that it’s less fun or somehow a display of weakness to use other people’s code. Some of this is legitimate in that it can be dramatically less fun when the code doesn’t perform as advertised (or doesn’t advertise how it performs). Additionally, various propagandists tend to make it sound like the job of developers will ultimately get reduced to hooking together a bunch of preexisting components with no original work involved. People need to be reminded and reassured that there is going to be a continuous need for new components and that someone needs to build those. Reusing other components then lets you focus on the core of the new component you are working on, and gives you the time to make that system excellent as well.