https://austinvernon.site/blog/softwareisprocess.html Summary from Vernon 1:
I think the idea is that the world’s so complex and we really underestimate that complexity. If you’re going to digitize processes and automate them and stuff, you have to capture all that complexity basically at the bit level, and that’s extremely difficult. And then you also have diminishing returns where the easily automatable stuff goes first and then it’s increasing corner cases to get to the end, so you just have to go through more and more code basically. We don’t see runaway productivity growth from software because we’re fighting all this increasing complexity.
Vernon starts out with this idea that computers are kind of considered a GPT2. This liberalisation of information processing and access. He argues that, in fact, computers are a technology of the more managerial shallow kind.
Management techniques are a technology in a broad sense of the word. Assembly lines are one prominent example. Management techniques are fiendishly difficult to adopt. Improvements in management manifest as differences in company productivity that force most competitors to bankruptcy or merger, if competition allows.
Because computers lack tacit knowledge, instructions must have bit-level detail. A supervisor can’t walk up to a computer, show it how to attach a fastener, then walk away. A program has to be written by a software engineer that details every actuator movement in sub-millimeter detail.
Like this quote
Software engineers improve the ability of software to absorb more of our complex world.
He uses the system thinking concept of bottlenecks which I’m not too familiar with. I think the example tries to illustrate that in the real world you can have bottlenecks in the form of silos, a critical area of the company that is enmeshed in many processes.
No one creates software for processes that underly their [a companies] unique competitive advantages.
I don’ really understand this thinking
Silos also tend to use pidgin languages and force employees in non-critical departments to learn them. Completing a complicated form if you need parts from the brass works is an example. Generic software might not mix well with the company’s core processes. Because the software added to excess capacity, the only way to earn a return is by layoffs. Companies are laying off workers that understand how to interface with their unique processes!
Software in the waterfall method was obviously a massive failure but through learnings from the Toyota production system, things like lean where you produce smaller components that are non variables or that can be produced reliably as well as iterating to use ‘tacit knowledge’
If you give an Agile software team requirements for the software you need, they automatically assume those requirements are wrong. Instead of building what you ask, they take a small piece and hack together a prototype and then get your feedback. Then they do it again and again. The team continuously improves the software based on your needs that are difficult to communicate.
You don’t get productivity growth until the company becomes a giant.
One of the examples used, if you’re trying to ‘simulate’ or codify the real estate industry down to the ones and zeroes its just too large to really even start working on with no idea of return on investment. Im unsure where the nature of the firm fits in here
Imagine the entire real estate industry (including agents, financiers, inspectors) all agreeing on standards that have detail at the bit level. Now you know why we have iBuyers instead. Current software reduces the costs within firms more than it reduces the cost of market transactions.
- Languge.
- Clothing.
- Money.
- Electricity.
- The wheel.
- Fire.
- Steam engine.