Putting The Plan Together

In the last couple of posts I wrote about differentiation and technology choice. Both of these have a strong connection to previous pieces on the supply chain and commoditisation, and all of them are directly relevant to the work that software developers do on a daily basis.

As I recently declared, software is a factory in digital space, the digital factory. This factory evolves over time as part of a project. Developers plan production processes, machinery and a supply chain that will produce, at a scale with no real limit, a range of digital experiences on-demand. Depending on the particulars of the software, this factory may be an abstract concept and realised through a collaboration between seperate entities (e.g. a mobile app and the cloud). Despite this we can usually think of publicly available software as a collection of hundreds of thousands to millions of digital factories that may be in simultaneous operation.

For various reasons (such as variations in the device, versioning, and user accounts to name a few) these factories are not quite identical despite generally being expected to output identical products. To meet this expectation to the fullest extent possible, the parties that constitute the digital factory must be broadly interoperable across a field of acceptable combinations.

All of these considerations help shape The Plan. I want to be clear that when I use this term I am referring to the work that software developers do, as opposed to a project timeline, which is more of a description of intent (or a wishlist) than a description of how outcomes will be realised.

The Plan is expressed in code - although it often does refer to outside sources of data and how to interact with them - to achieve the outcomes expressed during specification.

The Plan as a whole describes how data is obtained and shared throughout the lifecycle of an application. Forming a complete model of The Plan for a large software project can take years. In part because of how the work is broken up, software developers are typically laser-focused on a small slice of The Plan at any one time.

As The Plan grows, opportunities for synergies emerge. If a software application has many different features - suppose it is 10 - that require a user account, it is often better to obtain information about the user account once rather than 10 times. And so it is that the production processes in our digital factories may become intertwined. This is an example that is shared across many, many kinds of software applications but rest assured that the principle applies more broadly in ways that will be particular to a project.

The Plan may have issues. The most clearly observable to all stakeholders in a visual sense are in design. If the social context driving the product (and hence the specification) is sufficiently dynamic, this is another path to defects in The Plan where teams are unable to align on differentiation. When The Plan is conceptualised but before it is realised, software developers make technology choices to reduce the time and effort to realise The Plan using the digital supply chain. Sometimes these delegations in The Plan are the source of issues in our software - as a developer it pays to bear in mind that they are also software projects, with processes, machinery, supply chains, fields of truth and a fog of war of their own.

As I alluded to in the post about code, The Plan is not the factory, but it is useful in understanding it. It is a description of what should happen, from at least the perspective of one party. When we have multiple pieces of software interacting (such as when a mobile app interacts with the cloud) there is not just one version of The Plan, each party has its own version of The Plan. If these visions of The Plan are not coherent, we will have a broken handshake agreement.

A broken handshake agreement can look like: a form (as in paper) with one required field missing or a phone number written in the name field. Humans are generally relatively tolerant of such situations and have little trouble reconciling them. Computers traditionally have certainly not been so forgiving. One unexpected result is often one too many, and as I've written in the posts about the internet, the device, versions, deployments, the supply chain and here in this article, there is a field of truth, and many, many pathways to one unexpected result.

Until next time.