We've been doing some planning 'round these parts - planning that I unfortunately can't talk about - but it's led to a fair amount of discussion about architecture, both inside the team and outside the team.
Which has got me thinking about reuse.
Reuse has been one of the Holy Grails of software development for a long time, along with... Well, work with me, I'm sure there are others. True AI!. That's another.
Anyway, reuse has been discussed since time immemorial (October 13th, 1953), for some pretty sound reasons:
It seems that if we did a little more planning, paid a little more attention, were just a little smarter, we could build our components in a more general way, and others could benefit from them.
And yet, people have been trying to do this for a long time, and have mostly failed at it. There are successes - widely-used successes - but they're fairly small in number. Surprisingly, people are still optimistic about going down the reuse path, and since they are likely to fail anyway, I therefore present some rules that can help them get there faster.
Authoring reusable components:
In my experience, that's more than enough by itself, but it helps if you can throw in some obscure algorithms and quirky coding styles. I'm already assuming that you don't have any real tests.
Consuming other people's components:
I hope these tips help you.
If you're a bit leery of reuse, then good for you. I have only a few thoughts to offer:
If you're thinking about doing something, it's always a build vs buy decision. Even the best general-purpose framework out there is just that - a general-purpose framework. It's not designed to do exactly what you want to do.
In the abstract, there are three phases of using a component in your code:
Phase 1 is great. The component is doing what you want, and it's quick and easy to do it. Let's say for sake of argument that this gets you to the 80% point in your project, and it gets you there quick.
Phase 2 is a harder. You're starting to reach the limits of the component, and it's tough to get it to do what you want. Tough enough that it's taking more time, and you're using up the time that you saved in phase 1. But you still feel like it was the right decision.
Phase 3 is much harder. It's taken you as long to get here as a custom-written solution would have taken, and making further progress is considerably slower than if you had written everything. Worse, you can see the point where you'll reach a wall where you can't do anything more, and it's close.
Different projects obviously reach different phases. Some never venture out of phase 1, and others are deep in phase 3. It's hard to tell where you'll end up, but if a given component is central to what you do, you are much more likely to end up in phase 3.
The obvious problem is that prototyping is always done in phase 1, and the rapid progress you make there is oh-so-tempting. The whole application UI is laid out in a week of work using Avalon. I got this demo with moving pictures done in 3 days using XNA. We all want to believe that it's really going to be that easy.
Stay strong against the lure of the siren song.