| I think I have to quibble with this: > Here, I propose Scott’s Law: never put order in a system before you understand the structure underneath its chaos. James C. Scott wouldn't probably never underwrite re-ordering of systems from the top down. Central to his argument is that viewing complex systems from any singular position requires a process of simplification (legibility) that prevents a complete understanding. The presumption that one has gotten to a place of "understand[ing] the structure underneath [the] chaos" is in fact the false confidence he attributes to most of these ordering projects. I think if you want to wrangle a suggestion from Scott's book, it's more about making lots of small pokes at a system and seeing how it reacts, and slowly building on positive reactions from the system. (Also, messiness and complexity are not intrinsically linked to the efficiency of a system — systems can optimize for lots of variables and it's really context-specific. So as much as you shouldn't take order to be innately good, don't take messy to be innately efficient!) |
I can feel a bit for it. I have worked on a complex multi-million line codebase. There was this predictible behavior when a new guy came to join us. Many times they had never worked on such a large project.
First they rant about how terrible the system is, than tell us how wrong the system is, followed by advice about how we should use this an this method or design patterns to make things right.
Only after months of working with the code the guy would cool down. When a (software) system is really complex, you have to get familiar with it. No matter how you structure it, a minimum number of logic and dependencies will always exist. Restructuring will not take away the complexity. It's just replacing them.
Offcourse a clear structure is better for you're understanding than a messy one, but even in the most clearly written code a lot of complexity can exist. I think Scott is talking about this, the point beyond clear structure.
thats complexity :)