The space shuttle is a great lesson for people about what NOT to do in engineering. Aside from violating every principle of KISS it basically asked all the wrong questions and as a result came to all the wrong conclusions. Consider reuse as an example. If you are going to make something more efficient by reuse the key question is where is it most important to save. With space launches the answer is so easy as to be trivial: the one thing you need to save is fuel. Fuel is the basic driver of cost for getting things in orbit. Always has been and until there are some major changes in technology (space elevator, anti-gravity, magic, whatever) it will continue to be. Now consider what the space shuttle did, it basically said the key thing we need to reuse is technology. These things are hard to build so let's just find a way to use them over and over again. All it cost them was... fuel.

Every time I saw a space shuttle coming down for a landing I thought to myself, "Wow, why are they taking a perfectly good space facility out of orbit again?" Not just the shuttle itself, but basically everything that made it to (or near to) a stable orbit was just dropped right back to the ground either being destroyed or being rebuilt so it could be thrown back up in the sky again (The boosters don't count because they never achieved enough velocity so they were brought back down in a very sane way). It always seemed to me that if we were going to send something as immense as a space shuttle in to orbit it darn well aught to stay there and get reused in orbit (or beyond). After all, a space shuttle is an awfully big thing to be doing nothing more than bringing half a dozen people back home. If we could throw the people out the door with nothing more than a parachute and a couple of down parkas I'd say go for it.

Now I'm no rocket scientist and this isn't a space blog so I won't dwell too much on how backward this approach is. Instead, I'd like to use it as a brief lesson on how to think about reuse in software. The first question is the same, what do we hope to save by reuse (what is the most important quantity in development). The answer: developer time. No quantity is more expensive than developer time whether spent designing, coding, documenting, or maintaining. Further, the practical reality is that most development time turns out to be maintenance and not any of the other aspects (although if you get good enough at it this can become much less true). In general I think that total code base size is a very reasonable surrogate for net developer time.

If you've followed me so far you may be tempted to say cool, that means that code reuse is pretty much a good thing since it will save developer time and developer time is the rocket fuel of the software engineering process. Not so fast NASA girl. What I've said is that reuse is good if AND ONLY IF it leads to saving developer time. Reuse does not by any stretch of the imagination always result in savings of developer time. Simple reuse pretty much always does (like a method in a class that you factor out of two locations and then use over and over rather than cutting it and pasting it around) and I'd go so far as to say almost any re-use case that results in a net reduction of code size within a project is probably a good idea. Forward looking reuse, however, is dangerous ground and reuse of large components from other projects for small tasks is suicidal.

When you grab some pretty healthy chunk of code from project A and pull it in to project B just because you need some small feature (all in the name of reuse) you've just launched the space shuttle in to orbit with an extra couple of tons of weight for no good reason. Your code base is bigger and more complex than you needed and your time savings for bolting that baby on (if there is any) is probably gonna be subsumed in spades in future maintenance and changes. If the two projects are also now joined at the hip (shared components rather than cut and paste seems like good re-use) you've also added some project management and code management overhead to BOTH your projects to boot.

Forward looking reuse is a little bit less dangerous. If you are really sure you will need the component again in the future and you are really sure you know how it will be used, then go ahead and do it, but unless you are a solid domain expert and this is the second or third similar project don't be surprised if your project caries a bunch of extra weight around (eats up fuel) and you never see any return for that investment.

So my short rule on safe reuse: if it makes your code base smaller now then HELL YES BABY, YOU THE MAN! If it makes your code base smaller in the future then well, maybe but you better be sure. If it will never make your code base smaller then DUDE, WHAT ARE YOU THINKING! As in all things there are exceptions; use your Jedi mind powers grasshopper.