How Mainstream Can Code Scavenging Go?

The time-honored tradition of code scavanging has long been a way for new programmers to "break in" to a new language or task that they may not want to build from the ground up. The re-use of old code, cleaned up and tweaked to a new purpose can help developers learn many useful skills and accomplish tasks quickly, especially for small tasks that aren't of vital importance. One blogger wondered if this process could be formalized and tools could be built to help foster and enable code scavanging on a mass level. Is this a viable option, or are there just too many things to consider?

Comments

Re:IP Laws?

[caffeinemessiah]

So, how quickly would you run afoul of Intellectual Property laws doing this?

That's a great knee-jerk reaction. Without understanding the motivation behind the article, you assume that code scavenging means stealing other people's code. What they're really talking about is (legitimately) re-visiting code that you or other people have written, and then picking and modularizing bite-sized chunks. In other words, you would design a large program (mark I) and then go back and pick out useful parts, clean/debug them and have working modules (mark II) for the next project.

Also, for people who haven't read TFA, it's 9 short paragraphs long and barely an article. They talk about a "formal approach to code scavenging" without even coming close to explaining what exactly that MEANS.

Re:It's called a "subroutine library"

[Anonymous Coward]

Seriously though: welcome to CPAN.

Re:Vernor Vinge

[bcharr2]

Code is basically an algorithm that solves a computational problem. So yes, you can cut and paste algorithms. If you want your application to be maintainable, however, you also have to solve the larger architectural problems, which is something you DON'T get when you cut and paste code.

It is one of the most misunderstood concepts about programming. A programmer fresh out of college knows how to write algorithms really well, but has no idea that there are architectural and design land mines waiting for them just down the development road.

Too many development shops will get an app "working" and think that is all there is to development, because no one has the depth of experience to look a year down the road and see that they will need to rewrite the entire app from scratch in order to make the simplest of changes.

I'm sorry, but if your program is not extensible nor maintainable then you really haven't "succeeded" at anything. You've simply fooled yourself into thinking the process is simpler than it is while screwing your clients out of their development dollars.

Re:Vernor Vinge

[Alphager]

The method of assigning homework is to give 3 lines on what a program needs to do. For example, write an FTP client that you can use to download a file. The method of grading is if you can download a file or not. The decision on how to get the HW done with the least amount of time spent is an architectural challenge.

Which is what the parent hates: people who only think about getting the product out of the door and who sacrifice things like maintainability.

Even firefox and Mozilla did a few complete rewrites of the various parts. Rewrites are part of programming unfortunately. The nice thing about rewrites is that the programmers now have experience on how to do things better and are able to better compartmentalize the code. I wouldn't say rewrites are terrible things - though they do annoy management and people above to no end.

Firefox & Mozilla are prime examples of bad codebases. We all know the disaster that was the last rewrite in-house at Netscape.
_SOME_ re-writes are necesary and usefull, but a company where the usual way to add a new feature is a re-write of the whole software is doing somethign wrong.

Re:IP Laws?

[alex4u2nv]

These are the ideas that CPAN, PEAR and other code repositories are built on. So instead of trying to reinvent the idea, the author should have poked around a little more, and to learn more about what is available as opposed to trying formalize a "hackup job."

The parent makes a good point here, where you should take the time to build a clean library base to work with. If one should have a well structured infrastructure, and should they need to implement a certain feature, more often is the case, that a generic library to facilitate the need already exists. If it's open source you're in luck, if it's commercial, you could license it. For example, take a peak into the game industry. A lot of those engines libraries are licensed out to many companies.

Now I will assume 'bits and pieces' is nothing more than 1 class, or a function. So, If one should be looking for bits and pieces of codes, as a developer you should be able to develop at least that much.

"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?...," TFA

The short answer is No.
This sort of programming will not make you a master programmer, it will make you a master scavenger.