Notes Information Apocalypse

Frameworks and Seedworks

Frameworks are the central technological obsession of this current era of web development and there are many benefits for designers and programmers to focus technical solutions around a given framework as a platform for reuse. Saving time, and doing away with the necessity of reinventing the wheel are the obvious considerations. The ecological nature of open source software also means that the most widely used frameworks are going to be more stable and secure, through the process community feedback giving rise to continuous bug fixes and improvement.

The idea of a seedwork is a contrasting side to this story which is less commonly talked about. The difference between a seedwork and a framework is in the way that reuse is controlled. Frameworks have strict patterns and common pathways for extension and implementation, wheras seedworks are oriented towards being hacked and 'grown' towards the final goal. Commonly, a seedwork would be a collection of lightweight skeleton classes which are ready to be imported, modified, and expanded to fit the demands of a particular situation.

Does this lead to cut and paste chaos? Not necessarily. I suspect that nearly all software developers at some stage in their careers will have created something like a personal collection of functions and classes that they reuse, and it's this context that is key to understanding the benefits of a seedwork. When you know your code well, you have awareness of its strong points and weak points. Unlike a framework, you don't struggle against an outside definition of functionality, or the mental effort of having to plunge through an abstraction boundary into the blackboxed internals when something doesn't work the way you'd like it to. Seedwork code is explicitly written to make it easier to dive in and rework for a particular situation.

Seedworks are also interesting for prototyping architectures that may later be extracted into a fixed framework. There's usually many different ways to solve any given coding problem, and I'd put my money on the most successful and usable frameworks being those that have the experiences of trial and error feedback and exploration embedded in their DNA. Starting from a seedwork seems like an ideal way to evolve a framework, by understanding and extracting the parts that matter most.