4 ms·

> Conclusion We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the bas

by User23 5y ago

> Conclusion We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules. This aligns well with my experience, even if the terminology feels a bit dated.

nerdponx 5y ago
This is a great piece of advice and definitely applies to software development in 2022. It probably even applies to system and organization design in general.
- toss1 5y ago
  Yes, isolating design decisions and modules that can change independently is fundamental. I also found one of the essential keys in the first paragraph, which unfortunately didn't seem well discussed in the paper: >> At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules I've found it extremely useful to clearly and fully define the interfaces before coding. When this is done well, it should be the case that separate (module) teams can really develop and even test independently, as they are really just "throwing it over the wall" when communicating with another module. This also enables far easier scaling, as one can focus scaling (e.g., adding more hardware) to just the essential parts of the system. So, it ends up being worth it to even either deeply analyze the range of possible interactions between the modules, or even build small simulators or throwaway versions just to really understand at the outset the elements needed in the interface.
deleted 5y ago
[deleted]
_0w8t 5y ago
There are clear cases when the approach advocated in the paper just does not work. For example, one cannot hide behind an abstraction the difference between a reliable local and unreliable network storage. Another problem is that designing module boundaries to minimize the future changes require to anticipate what may change. But as the saying goes, “it is really hard to predict especially about the future”. If the prediction was wrong, then the initial split into components was hiding the wrong thing. For example, in the example in the paper they assumed that the task would stay the same, only hardware or the size of data set would change. But allow to change the task, and the whole proposed module split becomes wrong while design based on what was called flowcharts in the paper could require less rewrites.
- Jtsummers 5y ago
  > There are clear cases when the approach advocated in the paper just does not work. The paper calls for being deliberate in how you modularize your code. So is your alternative to have, what, no modules? To just arbitrarily divide your code between modules? If you have modules (whatever that means in your language(s)) and you don't consider how to divide your code across them, you're inviting trouble because now you're just being cavalier and avoiding the task of thinking. Not being deliberate is careless. > For example, in the example in the paper they assumed that the task would stay the same Yes, he did do that. Both versions, however, largely make this task independent of the modules other than the master control module by putting the KWIC task into master control module itself. All the other modules facilitate the KWIC task and the master control module plumbs it all together. In either design, a change in the task will require changes to a variety of modules but will require changing at least the master control module in both cases. How many other changes are needed? Who knows! Depends on how big a change we're making to the task. The second design, though, leaves the facilitating modules more independent of each other, in a "what do they have to know about each other" sense. The line storage is presented as an interface, none of the other modules have to know how it works, just how to work it. This is in sharp contrast to the first design, where the line storage model is explicitly known by each of the several modules, and any change to it requires changing most of the program.
  - 5y ago

by User23 5y ago

nerdponx 5y ago

This is a great piece of advice and definitely applies to software development in 2022. It probably even applies to system and organization design in general.

toss1 5y ago
Yes, isolating design decisions and modules that can change independently is fundamental. I also found one of the essential keys in the first paragraph, which unfortunately didn't seem well discussed in the paper: >> At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules I've found it extremely useful to clearly and fully define the interfaces before coding. When this is done well, it should be the case that separate (module) teams can really develop and even test independently, as they are really just "throwing it over the wall" when communicating with another module. This also enables far easier scaling, as one can focus scaling (e.g., adding more hardware) to just the essential parts of the system. So, it ends up being worth it to even either deeply analyze the range of possible interactions between the modules, or even build small simulators or throwaway versions just to really understand at the outset the elements needed in the interface.

deleted 5y ago

[deleted]

_0w8t 5y ago

There are clear cases when the approach advocated in the paper just does not work. For example, one cannot hide behind an abstraction the difference between a reliable local and unreliable network storage. Another problem is that designing module boundaries to minimize the future changes require to anticipate what may change. But as the saying goes, “it is really hard to predict especially about the future”. If the prediction was wrong, then the initial split into components was hiding the wrong thing. For example, in the example in the paper they assumed that the task would stay the same, only hardware or the size of data set would change. But allow to change the task, and the whole proposed module split becomes wrong while design based on what was called flowcharts in the paper could require less rewrites.

Jtsummers 5y ago
> There are clear cases when the approach advocated in the paper just does not work. The paper calls for being deliberate in how you modularize your code. So is your alternative to have, what, no modules? To just arbitrarily divide your code between modules? If you have modules (whatever that means in your language(s)) and you don't consider how to divide your code across them, you're inviting trouble because now you're just being cavalier and avoiding the task of thinking. Not being deliberate is careless. > For example, in the example in the paper they assumed that the task would stay the same Yes, he did do that. Both versions, however, largely make this task independent of the modules other than the master control module by putting the KWIC task into master control module itself. All the other modules facilitate the KWIC task and the master control module plumbs it all together. In either design, a change in the task will require changes to a variety of modules but will require changing at least the master control module in both cases. How many other changes are needed? Who knows! Depends on how big a change we're making to the task. The second design, though, leaves the facilitating modules more independent of each other, in a "what do they have to know about each other" sense. The line storage is presented as an interface, none of the other modules have to know how it works, just how to work it. This is in sharp contrast to the first design, where the line storage model is explicitly known by each of the several modules, and any change to it requires changing most of the program.
- 5y ago