Sunday, July 10, 2005

Scaffolding

Scaffolding is crucial to building construction. A scaffold does the following:
  • enables builders to access parts of the building
  • interlocks with other scaffolding easily
  • acts as a staging area for further construction
  • can act as a conduit for more materials
  • holds the building up
  • protects builders
  • protects passers by
The Goo needs to use scaffolding too. But unlike building scaffolding it doesn't have to be taken down after the event. We've got oodles of disk space now. We can afford to employ extra artefacts in the process of software construction. Why stop at unit tests and documentation?

Remember the "software requirements specification"? It hung around a project like a bad smell - most people ignored it. If it wasn't wrong in the first place it soon went out of date as the software inevitably changed. Software scaffolding, like the software itself, must be malleable. Wouldn't it be better if the scaffolding emanated directly from the requirements? Even better again ... if the requirements were properly specified in the first place, so that the underlying "pain" is identified first, then the problem, people and solution. Even better again ... what if we could traverse the trails of association between all these things (pain, problem, people, solution) so that there was a shared software construction memory?

0 comments: