Reuse

You’ll have heard about this reuse “thang.” Chapters within this very book look at it, and software pundits have been sky-writing the word “reuse” for decades. Reuse is important to companies who build a lot of software because it means that they don’t have to build everything from scratch—an “old” component can be used in a new system. Reuse is what made cars a practical, affordable proposition for lots of people. (We won’t debate the issue of how that has worked out.) Reuse is the idea of taking components and building systems from them. But you know all this—you read the magazines. The reasons for coveting reuse are numerous, but none are as key as these two: you can build systems quicker, and you can build them more complex. Both reasons can be used as cost arguments, so when you justify the costs for a project, the numbers could look a bit better if you factor in reuse. Then how come we’re not all already reusing components and taking this process for granted? Well, you have to have built your components in the first place, of course. This is the first major hurdle to reuse, especially since many organizations that are project driven in their Information Systems (IS) efforts fail to take the long view, which involves spreading the cost of building some reusable components across more than one project. The second hurdle is to make it easy to reuse what you already have—but I’m not writing about repositories just now. To do reuse, you have to do it—it doesn’t just happen like rain and taxes.