The Division of Labour

In my last post I wrote about code and how it was important to understand that there are many quality metrics by which code can be considered 'good' or fit-for-purpose, and many of those metrics are in conflict with at least one other metric - with all of them are in conflict with broader project success metrics of time and cost.

I mentioned a process in which code is transformed into digital experiences and toward the end of the piece, that there are division of labour in software development. Let's explore that further - the transformation of code into digital experience is a suitable starting point. This process is a natural place to aggregate effort as it is well beyond the concerns of any one company - every software developer in the world is interested in taking code and transforming it into a digital experience. There are more specific kinds of shared concerns. For instance, many kinds of mobile apps are interested in sending push notifications to their users, or sharing photos from a device camera to a particular mobile app. These are all problems that transcend the requirements of any one particular piece of software, and so it has transpired that solutions to these (and many other) problems have emerged from a large pool of contributors with a diversity of relationships to the craft - hobbyists, independent contractors and employees of companies of all sizes. The motivations of these people have some say in the 'shape' of their solutions, or as I spoke to in the last piece, the prioritisation of code quality metrics. In practice this can mean that as software projects scale they outgrow solutions they once delegated - they are no longer able to externalise certain aspects of the divisions of labour. It is worth mentioning that for many software projects there is no direct financial relationship with third-party dependencies, which in practice is consequential to say the least.

The division of labour manifests itself in other areas of software development beyond collaborations with third-parties.

Readers with any level of familiarity with web development or software development may have some concept of a 'frontend developer' and a 'backend developer' even if they are unaware of what these roles are in a practical sense. It is common for features of contemporary software applications to be solved via emergence (as opposed to a single responsible party) and this stems from various practical considerations. The user of a mobile application expects that it will be relatively quick to download initially, and subsequently that it will be quick to update. The user will prefer to not be required to update this application. The producer will prefer to have a certain degree of control over the user experience that is as decoupled from the version of the software that is being used as is practically possible. To thread the needle between these concerns suggests a certain division of labour.

Suppose there is a some kind of problem with a particular application in production. Can we fix it? When can we fix it? How broadly will the fix be applied? When will the fix be applied? What about the users that we can't provide a solution for? The diffusion of responsibility has a strong say in shaping the answers to these practical questions.

I've spoken about developing features and responding to problems in production, but the division of labour shapes practical considerations that come much earlier in the software development lifecycle. Questions like "how long will this take?" and "how much will it cost?" are predicated on forecasts about what the division of labour for a particular project or feature within a project will be. Professionals do their best to make good forecasts with the information available to them. Sometimes, third-parties alter the deal.

I am altering the deal. Pray I don't alter it any further.
- Darth Vader, The Empire Strikes Back

When this happens, a project may be forced to take greater ownership of problems that once appeared to be safe to delegate.

In the last couple of weeks we've explored how code is not directly a digital experience, that code is not necessarily aligned with a targeted digital experience, how there are many axes on which code may be considered 'good' and the notion that a particular software project has third-parties it depends on that are not necessarily aligned to its own goals. There is still much to talk about. See you soon.