iconography

I’ve been thinking about how the current construction of the modern world (human-made objects) can limit our ability to reshape it. Let me explain using an example.

In programming, there is a concept called Object Oriented Programming (OOP). One of the problems OOP tried to solve was how to manage increasingly complex programs. In a more procedural style, code often acts on a shared set of data. That can work well at a small scale, but as lines of code explode beyond, say, 10k lines, it becomes harder to read, manage, and track the state of the data. Imagine your program is down, several customers are relying on it, and you can’t find the problem because too much of the system is entangled.

Enter, OOP.

OOP is designed to manage this complexity by dividing up the program into self-contained objects that bundle procedure and data together [1]. For example, an object that represents a shopping cart on a retail website. Another object that represents the search function in the same website. When the site is down, I can isolate the problem to a self-contained object or group of objects and understand explicitly what characteristics each object has and the self-contained data they act on.

So far, so good.

Here’s the problem. As OOP programs grow in size at a company, there is often division of labor. Engineering team 1 manages this set of objects, and Engineering team 2 manages that set of objects, and so on. In concept, this allows us to separate concerns, and reduce the burden on humans to understand the whole code base.

Good, right?

It can be, but who now carries the full picture in their head? Who carries the full expression of intent?

This type of labor specialisation existed before OOP, of course. But software architecture can encode that division of labor into the structure of the system itself. It’s much harder to rewrite.

This is a trade-off that is hard to see upfront and carries negative second-order effects. For example, a manager might come in and say “This program works, and served our customers in the past, but it doesn’t serve them well today.” Suppose the manager is right. How should all the objects, interfaces, and engineering teams be reshaped?

When a potential change requires something the program design doesn’t anticipate [2], the reaction is often to push back until engineers are sure that it’s true that the holistic expression of intent is wrong because otherwise reshaping is a lot of effort. And because there isn’t a clean way to decide on this question of intent, it can often lead to stalemate and stalled innovation.

Now think back to my first sentence. As the design and construction of the modern world becomes more complex, our ability to understand or remember the expression of intent of each object might be lost. When that happens, we might forget to question whether (a) the intent of each object is justified in its expression; and (b) whether all objects together sum to a faithful expression of our original intent.

In the worst case, the whole intent is wrong, and we aren’t positioned to notice or reshape it.

This seems relevant in the age of AI.

[1] How OOP is defined seems to be debated: https://en.wikipedia.org/wiki/Object-oriented_programming.

[2] See D.L. Parnas: https://www.cse.sc.edu/~mgv/csce590f20/ParnasCriteria.pdf