In the Winter of 2001 the US Navy began the re-development of the DD-21 destroyer class warship after Congress slashed the original budget. The new ship class DD(X) and named after Admiral Zumwalt was to be the Navy’s first fully integrated command and control (C2) vessel featuring a small crew, multipurpose vertical launch tubes, large flight deck, and with enough electric generation capacity to power small cities or the anticipated kinetic and laser weapons.
What was not divulged at the time was that the Zumwalt’s C2 left little need for fully sentient beings to operate the ship. It has been learned that a black budget division within the Navy’s Marine Mammal Program has been replacing the crew of the DDG-1000, currently at sea in the San Diego, CA area, with mollusks and cephalopods. Mollusks, due to their limited intelligence, (newly hardened) protective shells, and stationary nature, have been integrated into the ship-wide computing networks and are now responsible for intermediating with all sensors and actuators — from missile launch tubes to freshwater valves.
How far along the chain of command has been replaced with coleoidea is unclear. There is strong circumstantial evidence that the ship's captain is a human-octopus hybrid. The recent waterproofing polyethylene application to the inside walls of the ship’s bridge and mission control centers suggest that the hybridization is more octopus than human.
More news to come.
Furthermore on dashboards for maintenance developers
What would a dashboard for visualizing and managing the flow of messages between actors and their dependents look like? My skills run in the direction of information architecture and not visual design, unfortunately. I can tell you what should be on the dashboard, the relationships between the contents controls, the visual and interactive priorities of these, and how all of this changes over time. On a Friday night, this is not something I am prepared to do; which is really an excuse as I am nearing the end of my interest in this thought experiment. Nevertheless, here are a few ideas.
A display for showing details of actors, messages, and listeners (dependents) might be
The transitions of a message between the actor and the dependent are
- Actor sends the message to Dependent, or fails to send it.
- Dependent receives the message, or fails to receive it.
- Dependent responds with a response-message to the received-message, or fails to respond.
- Actor receives the response-message, or fails to receive it.
We can symbolize these statuses as
A display for showing details of actors, messages, and listeners (dependents) might be
Each message is given a row and the delivery and response status is detailed for each listener. My bare tabular example would have much more detail on it in practice. This is not a overview display and so concerns with overwhelming the user with too much detail is not of relevance. If you only have to show a few listeners and perhaps a brief time window of messages this display will quickly show specific problem with delivery and response.
Inverting and aggregating the above example leads to the tighter display
We are, again, showing each message, but the columns now indicate how many listeners are in each of the delivery or response states.
Lastly, as everyone loves a set of small multiples graphs here is 40 minutes of activity and status where the green line is the number of listeners, the black lines show positive trends and the red negative ones.
Man, that is an ugly chart (and is playing loose with small multiples).
More on dashboards for maintenance developers
Yesterday I wrote about providing tools to visualize & manage the internal workings of applications for maintenance developers. That note was long on advocacy and sort on detail. This note somewhere between those two.
We are all familiar with run-time debuggers. We can get our job done with gdb [1], but for day in and day out work a visual debugger is a must have. A debugger is a point-in-time dashboard of the execution of the programming language used to implement the application. It is not a dashboard of the application, it does not directly represent the application's data or processing models. Nor does it provide a history of where the application was or a prediction of where it will be heading too next. Nevertheless, it is a useful analogous image of the application dashboard to keep in your mind.
If, for example, your application relies on the observer pattern [2] then you will need to visualize & manage the actors (observed), their dependents (observers), and the messages. The effort to implement this dashboard can be significant, which is the exact opposite of implementing the pattern itself. The pattern is often implemented as a list of callbacks. This implementation is so insignificant that your high performing developers probably choose not to use a framework at all, but to re-implement for each use. And there is the root of the trouble ahead for the maintenance developers, there is no one place to watch this running application. Callbacks and messages are being created and dispatched all over the place.
Suppose there had been a reusable implementation. The management of the listeners was done in a single place. The dispatching of messages to the listeners was done in a single place. Each reuse required that the developer explain the purpose, configuration, and expectations of this reuse. For example, "Status of the nightly recalculations of base prices: the messages are life cycle events; messages are ticketed and numbered for correlation; the listeners can be local or remote; the listeners are contacted asynchronously; no receipt acknowledgement is wanted, but when given will be logged; expect a dozen messages over a 2 hour period in every 24 hour period to be sent to a few hundred listeners." When this pattern is visualized on the dashboard not only is the context clear, but timelines of planned to actual and switches to toggle synchronicity will automatically be included. And what if you could dynamically toggle receipt acknowledgement? How many of your application's ailments are the result of lost messages sent to remote listeners?
The rise of DevOps has brought with it both tools and new (renewed?) appreciation for visualizing processes and their artifacts. Lets keep on pushing these ever deeper into the application itself.
[1] gdb, https://www.gnu.org/software/gdb/
[2] Observer pattern, https://en.wikipedia.org/wiki/Observer_pattern
We all want visibility into a running application
We all want visibility into a running application. The need becomes acute when the application is ailing and that visible schedule, map, and cartogram of the data and processing will swiftly guide you to the failing part.
What is less recognized is that these same visuals are needed in maintenance. Your original, high performing developers are unlikely to be around after the application has been in production for a few years. They will have moved on to new green pastures. If you are lucky and they are still with the company then they will be somewhat available to the maintenance developers. If a little cantankerous about that.
The maintenance developer usually has little broad knowledge of the application’s operation. Her first task at resolving an application’s ailment will be to find suitable entrance and exit points. This is not an easy task for our applications now run continuously, across multiple processes and hosts, and are highly asynchronous. Hopefully, those high performing developers adhered to standards, used a common framework throughout, and kept to best-of-class external libraries and supporting tools. If they did then she might have a straightforward resolution path. In all likelihood, however, those high performing developers probably invented too much and documented too little. [I speak from the experience of my younger self.]
What the maintain crew needs is not logs alone. They need meta tools that connect to the running application and visually show its operation. Once connected the tool must be able to slow down the application to a human pace. Restrict it to one active user at a time. It might even need to switch it to run synchronously.
These are not easy features to implement, but the cost of not doing it is not just the ever lengthening backlog of ailments to fix, but the erosion of customer confidence and, in the end, loss of customers.
All modern applications have three users. The first is the customer. The second is the customer support. The third is the maintenance crew. It is way past time that the maintenance developer is provided the meta tools needed to look inside the running application and keep it fit for market.
Subscribe to:
Posts (Atom)