7 ms·

I think the most contentious part of the post is that I just simply assert that people are an inherent part of software. You often avoid the incidental complexi

I think the most contentious part of the post is that I just simply assert that people are an inherent part of software. You often avoid the incidental complexity in code by indirectly shifting it to the people working the software. Their mental models and their understanding of everything is not fungible, but is still real and often what lets us shift the complexity outside of the software. The teachings of disciplines like resilience engineering and models like naturalistic decision making is that this tacit knowledge and expertise can be surfaced, trained, and given the right environment to grow and gain effectiveness. It expresses itself in the active adaptation of organizations. But as long as you look at the software as a system of its own that is independent from the people who use, write, and maintain it, it looks like the complexity just vanishes if it's not in the code.

munificent 6y ago
> You often avoid the incidental complexity in code by indirectly shifting it to the people working the software. Yes, this is Larry Wall's waterbed theory: https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory I do think it's important to distinguish accidental and essential complexity. Some complexity is inherent and if you think you've eliminated it, all you have really done is made it someone else's problem. But there is also a lot of complexity that is simply unnecessary and can be eliminated entirely with effort. Humans make mistakes and some of those mistakes end up in code. Software that does something that no one ever intended can be simplified by having that behavior removed.