Friday, March 13, 2020

Steven Sinofsky on Crisis Leadership

I read the original Twitter thread and felt the need to be able to reread it, probably more than once.  Thankfully, an annotated version is now available on Sinofsky’s Medium blog.

It is worth reading.  It is worth understanding that any crisis arises and must be addressed under chaotic conditions.

There’s also the matter of preparation.  There can be strategies and plans for the foreseeable.  And, as is frequently reported, when the crisis erupts, the plans go out the window.  Yet we are better prepared for having done the planning, actually made the preparatory arrangements, and gained some level of training even if not the same as having been tested in response to a previous crisis.

Mel Conway on Humane Tool Design

Mel Conway has come up with a 85-tweet narrative on his view on having a universal-level arrangement for computational operations that is learned the way we all learned to listen, speak, move, walk, and explore as infants.  The idea is that we will ultimately grown up in this, whatever its forms, and it will have become a natural capacity.  Conway has an approach in mind.

The threads are all on Twitter.

Prelude (1 tweet)

0. Introduction (2 tweet thread)
A cloud-based Application Development Platform for the Rest of Us

1. Thesis (2 tweets)
-   If non-programmers are going to build real-world solutions, a simpler programming langauge isn’t enough
-    posits a collaborative situation in which everyone can participate with the skills they already have

2. Democratization of culture-critical information technologies (Historical Perspective: 16 tweet thread)

3. Universal Human Skills Model of Progress (16 tweet thread)

4. Humane Tool Design: 12 Principles (14 tweet thread)

5. On Platforms (20 tweet thread)

6. Where the Work Stands Now (17 tweet thread)

The proposed goal is a Humane, Asynchronous, Asymmetric Construction Platform for Stateful Business Applications

There is background material in Conway’s Humanizing Application Building presentation (PDF download).

I can appreciate the thesis, and I think Excel is a perfect illustration of the kind of collaborative participation that could be involved.  I would like to know more about what is essential versus incidental in the proposed cloud-based arrangement.

Above all, Conway’s thesis and narrative merits much thoughtful consideration.

Wednesday, March 11, 2020

Situating Performance Architecture

"Without the cognitive work that people engage in with each other, all software systems eventually fail" ACM Queue January 2020
It should be no surprise that our devices and computer software train us to learn how to operate with them.  We are the adaptable participants.  At the same time, we are not aided in formulation of conceptual models and practices that afford successful interactions.  

Perhaps the way to articulate my concern about this is by reflecting on a situation that was successful.  This was years ago; it is the handiest illustration that I have personal experience of.

Performance Patterns

The diagram below is a depiction that I refer to as a Performance Architecture.  It is a diagrammatic pattern that involves scanned images being captured and organized in digital form.  I term this an RSVP pattern: Read/render, Store, View, Print/present.



Used before Design Patterns became a thing in software development, the template for components of this pattern are very simple.



Based on the notion of dataflow diagrams, the indications of flow can be taken simply as transfer of data across a definite interface from one process to another process or storage.

By itself the RSVP pattern is abstracted at a high level above a detailed implementation case.  The pattern depicts an intermediate performance-architecture level.  Going deeper exposes more internal arrangements.  The surface at which users and operators approach and interact with the (sub)systems is also suggested.  At this informal conceptual level, fidelity of operation takes two forms.  There is specified technical fidelity to specified variations that an implementation supports.  At the same time, there is subjective (light-bulb) fidelity with respect to a particular usage situation and how that is satisfied by experimentation and confirmation of operation.

Customized Application



In an actual custom application, depicted above, the RSVP pattern was divided between two operations, 4.2 and 4.3, factoring the conceptual arrangement further.  Choreography with the additional activities involves considerable manual arrangements involving physical artifacts and a worksheet that is maintained throughout the progression of operations.
  
The purpose of creating digital images was preservation of scarce physical books that were deteriorating as the result of 19th century printing using papers produced via acid-based pulp-paper processing.  The phenomenon is evident in old paperback books and also old newspapers.  The book pages become brittle, discolored, and fragile.  In order to preserve the books digitally, the book is destroyed by removing (guillotining) the binding, separating the individual pages.  It is the individual pages that are scanned without any mechanical feeding, checked for successful capture of the pages, and then added to a digital collection with additional material for organization of the images as pages of a digital book. A printed and bound replacement book is produced and checked against the original pages.

Overall Situation


Rescue of deteriorating 19th century books was part of a prototype effort conducted to determine a successful preservation approach.  The effort was tied into an overall college-campus research library system.  Although the RSVP pattern occurs informally within activity 4.0, Make Digital Preservation, integration into operation of the research library and honoring of the sensibilities of the research librarians and curators was paramount.

People are not explicitly reflected in the diagrams.  There are human activities everywhere the physical and the digital are in conjunction.  Also, fine-grained iterations are to be understood.  There were provisions for rework and also correction from errors –- blemished scanning, pages out of sequence.  There also was a need for training of operators and supervision of operation.  Computer Center operations were relied upon for IT support. 

Although highly-tacit, the diagrams of this kind often serve as touch-stones for the participants to orient themselves with regard to their contributions and the overall enterprise.  It also reflects the constraints on subordinate procedures and what their architecture must serve in the higher level depiction.

This situating provided global context for agreement among the technical team providing the digital RSVP portions and the personnel of the library.  The entire undertaking was through a successful prototype codevelopment.  The digitally-preserved books are now part of an extensive set of digital collections made available on the World Wide Web.

There was important technology dependence.  Adequate preservation required high-quality flatbed scanning of book pages that was protective of the fragile pages.  High resolution xerographic printing of indelibly-fixed toners on archival papers was accomplished using an original Xerox DocuTech Network Publisher fed from a Unix server.


The configuration information is rather barren in the absence of the architectural patterns and the situating external architecture.  We get a view of what the system configuration is, but not what it is for.  And this is the most-replaceable component in the overall performance architecture.

At the intermediate and upward into the external architecture, there is a diagrammatic means for shared understanding and evolution of variations, improvements and extensions.  There is significant acknowledgment of tacit understanding, and a place for confirmation of consistency among those understandings between producers and those who adopt and employ the resulting system.

This case study is meant to be suggestive about preservation of end-to-end and user-situated understanding by sketches of this sort.  Whatever the form employed, distinguishing the levels and capturing the context in which built components must fit is important for understanding of the developers and those the development serves.