I don’t think the metaphor about writing code works. You say, “Imagine a company has to solve a problem that takes about 900,000 lines of code.” But in practice, a company never possesses that information. They know what problem they have to solve, but not how many lines of code it will take. Certainly not when it’s on the order of a million lines.
For example, let’s say you’re working for a pizza chain that already does delivery, and you want to launch a mobile app to let people order your food. You can decompose that into parts pretty reasonably—you need an iOS app, you need an Android app, and you need an API into your existing order management system that the mobile apps can call. But how are you going to know how many lines of code those subproblems are? It probably isn’t helpful to think about it in that way.
The factoring into subproblems also doesn’t quite make sense in this example: “Your team still has to implement 300k lines of code, but regardless of how difficult this is, it’s only marginally harder than implementing a project that consists entirely of 300k lines.” In this case, if you entirely ignore the work done by other teams, the Android app will actually get harder, because you can’t just copy over the design work that’s already been done by the iOS team. I feel like all the pros and cons of breaking a problem into smaller parts are lost by this high-level way of looking at it.
My null hypothesis about this area of “factored cognition” would be that useful mechanisms of factoring a problem into multiple smaller problems are common, but they are entirely dependent on the specific nature of the problem you are solving.
I agree that the analogy doesn’t work in every way; my judgment was that the aspects that are non-analogous don’t significantly distract from the point. I think the primary difference is that software development has an external (as in, outside-the-human) component: in the software case, understanding the precise input/output behavior of a component isn’t synonymous with having ‘solved’ that part of the problem; you also have to implement the code. But the way in which the existence of the remaining problem leads to increased complexity from the perspective of the team working on the bottom-left part—and that’s the key point—seems perfectly analogous.
I’ve updated downward on how domain-specific I think FC is throughout writing the sequence, but I don’t have strong evidence on that point. I initially began by thinking and writing about exactly this, but the results were not super impressive and I eventually decided to exclude them entirely. Everything in the current version of the sequence is domain-general.
I don’t think the metaphor about writing code works. You say, “Imagine a company has to solve a problem that takes about 900,000 lines of code.” But in practice, a company never possesses that information. They know what problem they have to solve, but not how many lines of code it will take. Certainly not when it’s on the order of a million lines.
For example, let’s say you’re working for a pizza chain that already does delivery, and you want to launch a mobile app to let people order your food. You can decompose that into parts pretty reasonably—you need an iOS app, you need an Android app, and you need an API into your existing order management system that the mobile apps can call. But how are you going to know how many lines of code those subproblems are? It probably isn’t helpful to think about it in that way.
The factoring into subproblems also doesn’t quite make sense in this example: “Your team still has to implement 300k lines of code, but regardless of how difficult this is, it’s only marginally harder than implementing a project that consists entirely of 300k lines.” In this case, if you entirely ignore the work done by other teams, the Android app will actually get harder, because you can’t just copy over the design work that’s already been done by the iOS team. I feel like all the pros and cons of breaking a problem into smaller parts are lost by this high-level way of looking at it.
My null hypothesis about this area of “factored cognition” would be that useful mechanisms of factoring a problem into multiple smaller problems are common, but they are entirely dependent on the specific nature of the problem you are solving.
I agree that the analogy doesn’t work in every way; my judgment was that the aspects that are non-analogous don’t significantly distract from the point. I think the primary difference is that software development has an external (as in, outside-the-human) component: in the software case, understanding the precise input/output behavior of a component isn’t synonymous with having ‘solved’ that part of the problem; you also have to implement the code. But the way in which the existence of the remaining problem leads to increased complexity from the perspective of the team working on the bottom-left part—and that’s the key point—seems perfectly analogous.
I’ve updated downward on how domain-specific I think FC is throughout writing the sequence, but I don’t have strong evidence on that point. I initially began by thinking and writing about exactly this, but the results were not super impressive and I eventually decided to exclude them entirely. Everything in the current version of the sequence is domain-general.