I really appreciate this distinction. In my work working with software teams, I’ve encountered a recurring challenge re: ways to encourage a locally (team-scoped) autonomy around the details of an initiative from “above” - course-to-fine offers a thought-provoking guide for how to approach the superficial tension inherent in that goal. ;)
Quite provocative. A siren warning against a priori design rigidity. The self-organizing pattern design algorithms might be mind-blowing as self-generating NFTs. Just a thought
I think the write up here is great, and the concept of coarse to fine is very useful to understand for anyone involved or wants to be involved in system design.
That said, something bothers me about the terminology.
Blueprints are usually just a coarse level description of the constraints of the system (e.g. what you said about where the houses go and where the farm goes and the boundaries between them).
Sometimes they might contain multiple levels of details. For example, a blurprint for building a house might describe the boundaries between rooms (doors/walls/windows), and at a finer level, it might describe where the core "fixtures" go, like faucets and toilets and bath tubs. These are constrained by the boundaries set at the higher level.
I'm not an architect or a civil engineer, so I don't know to what level of detail do they usually go, but my point is that blueprints per se are not at odds with the concept of designing coarse-to-fine.
When it comes time to actually implement the blueprint (e.g., build the house), the people on the ground will probably have a lot of leeway in how they handle the details.
The specific examples you gave in Part I strike me as examples of premature design that is divorced from reality.
The case of requirements-deriven engineering is something I'm familiar with. Where you have some sort of business analyst writing up documents describing the system in details that don't actually make sense when you put them together.
The problem here is not lack of coarse-to-fine levels of details. There usually *is* mulitple levels of details. They usually do lay out the general plan first, and describe the system at a coarse level, and then dive into the details as they go.
Rather, the problem is that it was all designed up front, without the feedback loop you get from working on something hands on.
My experience of programming is like this: you start with an idea of what you want, but as you start building out the thing, you start seeing and noticing a lot of things that you never thought of before. The act of doing creates new input to your mind; this is feedback. The feedback causes you to adjust/alter your plans/design. This process continues and that's why it's called a feedback loop, or "iterating" on an idea/design.
With premature design, you don't get any feedback, so there's nothing that informs your design; it's all based on ideas that haven't been tested.
When you design with feedback loops, you can change the boundaries at the upper (coarser) levels too, if after a while you realize that the way you have them now are preventing the system from evolving into the direction you want it to evolve. So you not only start at the coarse level and adjust the finer levels as you go over time, but you can also go back (or up) to the coarse level and adjust it too. Although it's usually costly, and it might only be a thing in software engineering, because of its mostly non-physical nature.
I really appreciate this distinction. In my work working with software teams, I’ve encountered a recurring challenge re: ways to encourage a locally (team-scoped) autonomy around the details of an initiative from “above” - course-to-fine offers a thought-provoking guide for how to approach the superficial tension inherent in that goal. ;)
Quite provocative. A siren warning against a priori design rigidity. The self-organizing pattern design algorithms might be mind-blowing as self-generating NFTs. Just a thought
I think the write up here is great, and the concept of coarse to fine is very useful to understand for anyone involved or wants to be involved in system design.
That said, something bothers me about the terminology.
Blueprints are usually just a coarse level description of the constraints of the system (e.g. what you said about where the houses go and where the farm goes and the boundaries between them).
Sometimes they might contain multiple levels of details. For example, a blurprint for building a house might describe the boundaries between rooms (doors/walls/windows), and at a finer level, it might describe where the core "fixtures" go, like faucets and toilets and bath tubs. These are constrained by the boundaries set at the higher level.
I'm not an architect or a civil engineer, so I don't know to what level of detail do they usually go, but my point is that blueprints per se are not at odds with the concept of designing coarse-to-fine.
When it comes time to actually implement the blueprint (e.g., build the house), the people on the ground will probably have a lot of leeway in how they handle the details.
The specific examples you gave in Part I strike me as examples of premature design that is divorced from reality.
The case of requirements-deriven engineering is something I'm familiar with. Where you have some sort of business analyst writing up documents describing the system in details that don't actually make sense when you put them together.
The problem here is not lack of coarse-to-fine levels of details. There usually *is* mulitple levels of details. They usually do lay out the general plan first, and describe the system at a coarse level, and then dive into the details as they go.
Rather, the problem is that it was all designed up front, without the feedback loop you get from working on something hands on.
My experience of programming is like this: you start with an idea of what you want, but as you start building out the thing, you start seeing and noticing a lot of things that you never thought of before. The act of doing creates new input to your mind; this is feedback. The feedback causes you to adjust/alter your plans/design. This process continues and that's why it's called a feedback loop, or "iterating" on an idea/design.
With premature design, you don't get any feedback, so there's nothing that informs your design; it's all based on ideas that haven't been tested.
When you design with feedback loops, you can change the boundaries at the upper (coarser) levels too, if after a while you realize that the way you have them now are preventing the system from evolving into the direction you want it to evolve. So you not only start at the coarse level and adjust the finer levels as you go over time, but you can also go back (or up) to the coarse level and adjust it too. Although it's usually costly, and it might only be a thing in software engineering, because of its mostly non-physical nature.