Software Reuse

(See also SoftwareReuseBook.)

SoftwareReuse is about reusing software. You can also say CodeReuse.

There is much misunderstanding about that topic in my opinion. Some think, CopyAndPasteProgramming (or CopyAndPasteReuse) is also a type of SoftwareReuse. I disagree.

I think, that SoftwareReuse starts with reusable software. Many people think, they can get the benefits of reuse just by grabbing any software and reusing it. This normally fails. The conclusion of many companies is that ReuseHasFailed -- but I just think that CompaniesHaveFailedToReuse.

Why do I not think, that CopyAndPasteProgramming is reuse:

Because it is just CodeStealing?. It leads to DuplicatedCode. You may get a temporary benefit of this (like any thief has) but in the long term you run into trouble. I saw code that was cluttered with comments like "When changing this, please also update that ...". This ends up in MaintenanceHell?.

A more elaborate discussion about reuse you can find in my article TheMythicalManMinute.

-- JuergenLindemeyer

CodeGeneration (the good kind, where you never edit the generated code) seem to be reuse of another kind. The concept is a bit tricky though and real understanding isn't all that common. Remember also: There Is NoSilverBullet.

CopyAndPasteProgramming is a type of reuse, whether you like it or not! The duplication is not an issue if you only have to maintain one copy. If the code is 'stolen' from a completely different software system, then the duplication does not add to the complexity of the software you are interested in. There is only a practical issue if you are charged with maintaining both software systems. There is only a moral issue if you are literally stealing copyright material. -- ChrisSteinbach

What is the difference between code use and code reuse? I think a lot of the discussion on ReuseHasFailed could be helped if that was cleared up. Perhaps this is best looked at using examples:

1. Developer writes a GUI app and everyone else in the office uses it -- clearly use

2. Bunch of developers create an OS or web server or database server, and other developers use it to create their appliance or application -- use

3. A developer creates a library (e.g. standard C/Python/Java libraries) for other developers -- seems like use to me, the library was written with that explicit purpose, and it had no original 'use', so you can't talk of it being 'reused'.

4. A developer copies a load of code from either

modifying it as needed -- this is reuse, but of an unfortunate kind, since it can be a maintenance nightmare, or at least it means you won't get the bugfixes to the original code.

5. A developer subclasses a HtmlParser? class to create a HtmlParserWithPrettyPrinter? class, possibly overriding some methods and adding others -- reuse - the original code has now been made to do more than the author thought could be done, and we have a new thing, a 'HtmlParserWithPrettyPrinter?' class without having to write the bulk of the code.

6. A developer finds some code in another project that does most of what they need. By some appropriate refactoring, they create a library of functions or classes (or even larger pieces such as executables or services), making them more generic if needed -- reuse

7. A developer realises that the code he is currently writing can be useful in other situations, and so is careful to structure so that it can be used without modification by subsequent projects -- sometimes risky, but if it works then it's reuse

8. Forking -- a new project that competes with or supercedes an old one, but comes from a common code base. You could argue this actually just use -- the code is still doing the same job it was doing before. On the other hand, if you didn't write the original, you've got a huge amount of functionality for free, which you are able to reuse in your project, giving you a massive headstart on a competitor that decided to write from scratch, so in that case it's reuse.

Am I thinking on the right lines? If so, the distinction seems to be based on whether the code had an original purpose or context, and whether it's now being used for that purpose. However, for number 3, in reality I think a library will almost always have had an original use, so this is really reuse, and reuse of the best kind -- often so good that it is invisible, and we don't think of it as reuse. In fact, you can probably say the same thing about number 2 -- things like database servers have come about because people realised it's better to implement data storage once and well, rather than badly multiple times.

5 seems to be OO only, and I think it's the reason why people have claimed OOP leads to greater reuse -- but is 5 really different from 3? Many procedural or functional libraries will be used far beyond the imagination of the original author. 5 is also very hard to do in general, and it is often rather fragile -- encapsulating rather than inheriting is much easier, but your 'new thing' is an illusion -- it's only because OOP is noun-oriented that you seem to have created something new and big with very little effort. In the functional world, your new algorithm, while it may be built out of other algorithms, doesn't appear to be a new, bigger version of them.

A separate question is why - why do we want to reuse software?

So I guess which ones are really 'reuse', and which ones are good ways to do it, depends on your aims.


View edit of October 29, 2009 or FindPage with title or text search