Pavlos (pavlos) wrote,

Pavlos on Software: The workpiece

One of the key things that you need to have in order to be productive is your workpiece. The workpiece is the thing that you are cutting, hammering, or assembling into shape, and which embodies your creative effort. In this series I'd like to explore the importance and the many facets of the workpiece with relevance to the making of software. The main theme of the series is that having a workpiece is a really good idea, and that many long-term problems in our field stem from its absence, or its inadequacy.

The characteristics that make a good workpiece are essentially those of a board game:

  • 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.

Tags: on software

  • On Myth

    Hey! I'm mostly living in my shell these days, but here's a long-overdue essay from my other blog. Paul and Alison in particular have been formative…

  • Chomsky on Gaza 2009

    Everyone should read Chomsky's excellent article on Gaza 2009. Usually, Chomsky on the…

  • New blog

    Hi! This is just to let you know that I exist, although I don't really feel that blogging about my life is very interesting any more. I still live…

  • Post a new comment


    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.