4 ms·
Most of the mess we have in programs is of our own making. Our inability to properly address changing (not complex) requirements. And sure, the world is messy.
by loup-vaillant 7y ago
Most of the mess we have in programs is of our own making. Our inability to properly address changing (not complex) requirements.
And sure, the world is messy. But some things aren't worth automating. I've seen a talk about how the guy was writing a program to generate invoices. Turns out invoices are incredibly messy. The previous system was an overly complex brittle pile of code, that didn't quite work. His approach? Solve the common case first, and let human handle the messy bits. He started by something very simple, that could handle 60% of the invoices. Then 90%. Then 95%. Then 99%. The he stopped.
With 99% of the invoices handled, he had a simple, solid system. The messy part was handled by humans, and they had the time to do so because 99% of the grunt work was taken away from them. Plus, they could trust it works because since those invoices were relatively simple, they could be automated reliably. I believe that approach can be generalised. As Mike Acton said: "solve the common case first".
That I believe would work to "solve the inherent messiness of the world". Automate what you can, let humans deal with the rest. Or don't automate at all, just give tools & tricks so humans can work faster.
Alternatively, we could adapt around computers. Before electricity, factories used to have a giant engine that powered everything through mechanical transmission. Wen electricity first came along, we did the same thing. But it turns out electricity is much easier to distribute at a small scale. So factories adapted, and instead of having a big engine at the centre, they started to have lots of small engines everywhere, close to where they were needed. I believe computers are similar: we started using them as glorified paper, but as we understand what they can do, we employ them in more efficient ways. But the interface of a computer (it can do anything!) is much more complex than that of an engine (it can rotate!). I believe we haven't found how to best make use of them just yet.
- yowlingcat 7y agoI really like your point about solving the common cases, but what you're getting at there is exactly what is the challenging part, not the mathematical part of it. How do you figure out what is the most important 60%, then 90%, then 95%, then 99%? How do you develop the judgment to know when 99% is good enough, or 95%, or 90%, or 60%? How does mathematics help you out with that? My point is that this judgment is the messy and valuable part. And to your point around the end, that you believe we haven't found how to best make use of them just yet -- I agree with that too, and that's why I think the work of writing software, or best practices, or sound theory is not fully established. To build good product does fundamentally require a pioneer spirit that can make compromises and negotiations and arrive at that sweet spot that's not quite 100% but high enough to be "good enough".