Scott Hackett at SlickEdit has blogged its time to update the time-honored practice of code scavenging. According to Hackett, taking a more formal approach could help to improve developer productivity.
He argues that, while software re-use has historically concentrated on higher level frameworks and larger objects, there are also potential benefits in using code scavenging to fulfill the smaller (and less glamorous) "bite-size tasks" that developers face every day.
Hackett makes some good points, but can scavenging for scraps really turn you into a master programmer, and is it possible - or even desirable - to institutionalize this "make-do" approach?
Code scavenging is seen as the most frequent and least complex way of re-using code and has been common practice at an informal level since programming first began. Programming is difficult to teach and most programmers learn their chops by looking at working code and using it as the basis for building their own programs. In other words, they "scavenge" the good bits and tweak them to a new purpose.
The term scavenging appears to have first surfaced as a formal concept in a 1992 paper by Charles Krueger of Carnegie Mellon University. It was tested by academics in the 1990s but rejected because it yielded few gains for a lot of effort.
According to Hackett, code scavenging is worth re-visiting because the Web makes it easier to find code and re-use it. He points to sites where massive amounts of existing code are available for potential scavenging such as Google code search, Sourceforge, Code Project, Microsoft's Codeplex, and O'Reilly's Code Search. Others include the Free Software Foundation (FSF), FreeVBcode.com, Freecountry and Freshmeat.
He accepts that there are a few problems with scavenging for "bite-size tasks" however. The tools to find code at this level do not yet exist and it is difficult to define and package small-scale code components so they are identifiable. You are unlikely to find what you want with a simple Web search
Techniques such as literate programming could possibly be used to create an appropriate syntax that makes small code components easier to define. But as programming guru Edsger Dijkstra pointed out many years ago, although mastery of language is just as important in good programming practice as mastery of logic and numeracy, it is not as common as it should be.
The biggest barrier to formal code scavenging, however, is the problem of trust. Programmers are, quite rightly, suspicious of code they did not create themselves and any scavenged artifacts will need thorough testing to ensure they do what they are supposed to do - and nothing else. This could be so time consuming as to negate any potential productivity gains.®