The Project: The Factory For Digital Factories

When I introduced the factory, I made the claim that software development is digital manufacturing, and I also claimed that every app is an on-demand factory for a portfolio of digital experiences. Both of these claims are true within the context of the framework I am presenting, and yet there is a piece missing.

I have previously mentioned that code is transformed from text and into a digital experience. This transformation is a production process, generally referred to in a casual sense as 'building the app', and the output is referred to as a 'build'. If our app is factory, and it is produced through a production process of its own, then it stands to reason that we may have a factory that produces factories.

The app, the factory for a range of digital experiences, exists purely in digital space. The outer production process (of building the app) that produces various app versions spans the physical world and the digital world. For projects where "the app" experience is emergent from interactions between systems there may be other production processes that bridge the divide between the physical and digital worlds. An example of this is a mobile app that retrieves content (such as the news), and there is a web app or some other kind of of software to manage and administer that content (which may be referred to as an admin portal, or a content management system). In this scenario, producing versions of the mobile app is one process, producing versions of the content management system is another, and administering the content in the management system is another process again. The divisions of labour and supply chains for each of these will be particular to a software project.

The natural name for the enclosure of the digital factory is "the app", or "the software". Its parent is the Project. Projects have their own supply chains, divisions of labour and machinery, although these are much more immediately recognisable to wider society than their digital children that I have written about so far.

Projects also have very different relationships to the concepts of primitives and commoditisation than apps. There are stronger commercial incentives, more stability, economies of scale and markets. Your email client is a an example of project-level software that is utilised by various classes of professionals beyond software developers. The programs that are used by developers to produce software of their own tends to be less stable than mass market applications like email clients, particularly for developers of mobile applications.

As a project spans digital and physical space, we should think about what happens in the real world. A project lives in a grander social context, the specifics of which will depend on the organisation that owns it. Software projects do at least one of: achieve profitability in their own right, or serving as a machine in a larger commercial process that is profitable overall. Traditionally the manufacturers of popular digital game consoles have lost money on the hardware component of their product, and reach profitability through the sale of one or more games and various other products in their ecosystems.

The organisation of a project team in the physical world may span multiple distinct parties that are not strictly aligned by common interest or ownership (such as in a client-agency relationship) in an arrangement that outside of the presence of a profit-exchange is not so dissimilar to the divisions of labour in digital space.

In the last post I related UX designers to the factory model. We will soon reconsider how the work happens, something first explored in breaking the work up and connect it to model of the project as a factory to see if we can draw some insights.

Until next time.