Knuth

Stasis Request Form

/ Adam / Leave a comment

MegaCorp Industries, Technology Process Technology Department (TPT)

Name of system ______________________
MegaCorp Technology System Identifier (MCTSID) ______________________
Stasis owner name and employee ID
_
Dates requested (Note stasis periods longer than one calendar week require separate forms for each week) ______________________
System criticality rating ______________________
User population ______________________
Justification for stasis exemption (Eg natural catastrophe, medical emergency impacting > 60% of team, multi-site build chain outage)
_
_
_
Evidence supporting (please link or attach)
_
_
_
Mitigations for risks accumulated during freeze period
_
_
_
Emergency roll forward procedure
_
_
_
Size of development-support teams for system ______________________
Plan for remediation and resumption of normal releases (Please link or attach if space insufficient)
_
_
_
Line of business management approval
_
_
_
Diamond band manager approval
_
_
_
Other notes or comments
_
_
_

Stasis control board approval meetings are scheduled twice weekly. Stasis requests not represented in the meeting will be automatically rejected. A separate form is required for each request.

This was written as

  • A sarcastic reaction to experiences with established change procedures in large bureaucratic organisations.
  • A tool for framing the costs and risks of not releasing software frequently, instead accumulating large changesets so every release is inherently major and complex. Many change release procedures privilege the cost of change, rather than the cost of stasis (for instance, missed security patches). The actual work of filling out and reviewing a change request form is Risk Management Theatre, the point of which is not the content but the time tax imposed on release frequency by filling out the form, in a belief frequent releases are necessarily rushed and unsafe.
  • A document from a dromological future where continuous delivery techniques such as those used by Google and other firms are widespread through the industry and therefore institutionalized. Consider Facebook changing the way privacy settings work for the seventh time in a year, or a university administration sending one of these forms to Donald Knuth for TeX.

The Napkin Scrawls of Dining Philosophers

/ Adam / 4 Comments

Technologists are, by their vocational commitment to new things, manufacturers and early adopters of language. Our commitment to language is however generally one of casual incompetence. The artifact being built, or fixed, is the focus of our attention, and the language referring to it is an after thought for the tormenting of poets, grammarians and the marketing department. Perhaps that’s as it should be, but it’s still a pleasure to read a book like Java Concurrency In Practice, which has a mastery of both language and its topic.

JCIP has already been well reviewed on its technical merits. [NB: These notes are also from 2006 and written about the first edition.] In summary, it’s a great reference. As the jacket copy points out, concurrency in software is both difficult to deal with and of renewed importance. Problems like these put stress not only on software artifacts being developed, but the context in which that artifact is built and used, like collaboration in its construction, or human and computer interfaces, or eventual maintenance. Java Concurrency In Practice also has some insights into this, but it’s not foregrounded, and seems worth exploring.

Continue reading →