Squeeze out the trickiest part of the problem, another part of the problem becomes the trickiest. A tale as old as time.
Today, it seems like the biggest opportunities will be in the third of my opening statements. Building systems remains hard. Can I assume you’re familiar with Amdahl’s Law? That’s what’s going on: a massive speed up on a portion of the problem, but as that portion speeds up it becomes less and less of a contributor to the overall speedup. Lowering the costs of the rest of the problem is work that remains to be done. It’s going to take a long time, because the real world is fully of sticky problems, surprising feedback loops, human stubbornness, and the occasional adversary.
– Marc Brooker, You Are Here
You squeeze out coding time, you’re still left with open problems like:
- Running software in isolated, trusted environments (sandboxes) and coordinating work between programs (agents, databases, etc.).
- Human think time, which generates things like taste, and deciding to include this feature instead of that feature because intuition says it will improve the software.
- Coordination and collaboration between humans, which generates recurring meetings (no, thanks) but also great ideas out of nowhere (that’s why we’re here!)
- Verifying what you’ve built and vetting that what you’re proposing to integrate (merge) into the software is any good.
Be careful not to squeeze out the costs that are actually valuable. Otherwise, you might end up with inversions like banks that operate vast airborne transit networks at a loss.