Seedwork

In the very earliest days of Object-Orientation, the OO advocates like me put a lot of attention into arguing in favor of reuse. Early on we talked about reusing of classes. Then we discovered that reusing individual classes, while it worked in some cases, didn't work so well elsewhere. So we got into reusable frameworks, which got us part-built applications of functionality.

On the technical side, this kind of reuse has been a success - just look at the large libraries available with such environments as Java and .NET (and not just OO - as CPAN demonstrates). But particularly on the business side, such reuse hasn't been so quick to appear. And of the technical side many people feel that many of the frameworks they deal with are too complex for their purpose, and this complexity gets in the way of making these things useful.

A recent weblog by Michael Feathers dug into this question, the resulting discussion came up with an alternative notion - the seedwork. A framework is supposed to be a part-baked application that you extend in controlled ways to provide what you need. A seedwork is some minimal functionality that you modify however you like to get what you need. Of course this means that there's no way for you to get common updates to the seedwork, once you grow it you own it. This is the kind of copy and paste reuse that many people, including me, deride.

Maybe I shouldn't be so scornful. Frameworks and libraries work very well when they are well-seasoned. But getting a good framework is very hard. Seedworks are not as useful as a good framework, but are easier to create and use. The point is not whether they are ideal, but just whether they are useful.

And even mature reuse can often be a problem. We still haven't really figured out how to deal with shared libraries that upgrade on different schedules. We've all moaned at Microsoft's DLL-hell. Just this week I found my RedHat system got wedged when I tried to install some software and found my version dependencies were all screwed up (that was half a day down the drain.) Maybe the versioning system in .NET will solve this, but so far it's far too easy for even good people to get nailed.

I've found that reuse (or avoiding duplication) within an application is vital. But reuse across applications is much tougher, primarily because an ApplicationBoundary is primarily a social construction. That's yet more evidence that reusable frameworks are much tougher than we think, and yet more reason that we should consider less perfect alternatives - such as seedworks.