Mining For Primitives & New Means Of Production

When I wrote about code I exercised a level of care not to ground the discussion in computing, holding the belief that while how computers work would have some influence, much about the challenges of software development could be grasped without learning a lot about computers. I have only grown more confident in that view as I have fleshed out the digital factory and written about the division of labour, the supply chain, commoditisation, and ownership and access rights.

Having said that, I will introduce a bit more about technological concerns here, specifically as they relate to means of production.

Something that I did not mention in the article focused on code is that it comes in many different languages, maintained by different organisations. To some degree there is a legitimate product differentiation between languages with different commitments (or as previously mentioned in other contexts, handshake agreements) in regards to how their code interacts with a computer once it is transformed into a digital experience. Another consideration is about ownership, and the ability to shape the development of a language over time.

This is relevant to the broader model of software as digital manufacturing as it contributes to an understanding of the diversity of solutions available as a part of a possible supply chain for any particular software project. A language, the frameworks and other third-party solutions developed for it (as mentioned in the division of labour) are commonly referred to as ecosystems. There can be a high cost of switching third-party solutions, switching frameworks can be more challenging than that, and switching languages more challenging again.

When software developers have to create machinery themselves they do so with the primitives of a particular language (i.e. data primitives - how to represent a number or a sentence, or algorithmic primitives - how to represent work performed on data primitives), its building blocks. Two different languages may have natural primitives of a different scales. No matter the language, as projects evolve over time we typically develop a catalogue of higher-level primitives. At the moment this is a little abstract. Let's start thinking about pizza once more. If I am forced to produce pizza myself, my data primitives could be the ingredients I intend to use and interact with to make pizza happen. If I am able to outsource the production of pizza, the pizza that I receive from a third-party vendor would be a data primitive to me. A primitive is the smallest unit you have to think about, and its size is contextually dependent.

Much of what I've written so far is largely in terms of traditional software development, but for a number of years that has not been the only path to producing software.

A tension between businesses and technologists over a period of many years has been right-sizing primitives for the concerns of the moment as flexibility and immediacy are naturally opposed. Do we need a Facebook page? A HTML static site with a HTML component? Maybe a mobile app.

To navigate the trade-off of flexibility against immediacy newer methodologies have emerged, such as no-code platforms which allow the customisation of user-interfaces and data flows through user-friendly forms and more recently generative AI solutions which I have previously referred to when talking about the global digital supply chain.

In no-code platforms our natural primitives for a project are probably particular components and screens, and perhaps also the data that users may provide us. With generative AI solutions the natural primitives are less well understood and it remains a dynamic space. Today, many software developers interact with large language models in conjunction with code and there is much contention over the size of primitives. If the primitives are too small, it is perhaps not worth using the tools at all. On the other hand if developers work with primitives that are sufficiently large, they may not be able to guarantee correctness. Complicating the situation further is that in a similar manner to how there are many programming languages and frameworks, there are also a sea of LLM solutions, with different models, trained on different data, emerging in different sensibilities.

When I wrote about code one of the key points I made is that code is distinct from digital experience, meaning there is a layer of abstraction. An interesting feature of no-code and LLM workflows is that they introduce a second layer of abstraction over the digital experience. In the case of LLMs this second layer comes in the form of prompts. What we end up with are tensions between changing models, changing prompts, changing technologies (e.g. languages, frameworks, third-party solutions) with different forces pushing us in different directions depending on the project. This is all on top of the traditional tradeoffs that come with navigating code metrics and project success metrics.

It may well be that navigating primitives has never been more complicated than it is today.

Until next time.