- Everyone can examine the workpiece and see all that there is to know about its current state.
- Everyone involved can manipulate their pieces to change the workpiece, subject to some orderly rules
- You can attend to any part of the workpiece at any time, not necessarily from beginning to end.
- The workpiece is most interesting while it's not complete, yet must be valid at all times.
- Opposing forces control a workpiece, and the workpiece makes their interaction explicit.
The classic example of a workpiece that the software world has got right is the source code of a project. In a healthy project it exhibits all of these properties: You can inspect it in its entirety; developers can all make changes in an orderly manner; you can code and revisit any part at any time; it's rarely complete but should always build and run correctly; it embodies and usually exposes trade-off between performance, accuracy, and other relevant factors. In all, source code is an impressively good embodiment of the workpiece principles stated above and, I venture to say because of this, effective software-writing is often the least of a software company's problems. This getting it right hasn't come by chance either. Decades of thinking and effort have gone into the tools and processes that make code, essentially, a better workpiece.
The things that undermine the effectiveness of a workpiece are all those that sound mystical:
- Taboos: Possible configurations or paths to the solution that you are not allowed to contemplate because of politics or other relatively arbitrary forces.
- Relics: Pieces of the solution that you have to accept because they are (apparently) essential, but cannot change because the skills to do so are gone.
- Gurus: People that you have to rely upon to do things, but whose thought and work processes are essentially private and out of your control.
- Monoliths: Pieces of the solution that you have to incorporate, but which come in a form that doesn't admit change, or even inspection.
- Holy cows: People whose opinions you have to follow, or at least be seen to accommodate, because of their power over your work.
The management of a software firm is usually eager to to provide instances of these counter-examples in abundance, perhaps through pragmatism, or perhaps as a result of being incognisant of the importance of the workpiece, in software or generally. I think the latter is often to blame, so in this short series I will attempt to show how other artefacts of the software development activity can benefit from being molded to the workpiece principles that have been so successful with code.