No post body was provided.
On the criteria to be used in decomposing systems into modules (1972) [pdf]
31–33 of 33 posts
Re: On the criteria to be used in decomposing systems into modules (1972) [pdf]
#32> 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…
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.
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.
Re: On the criteria to be used in decomposing systems into modules (1972) [pdf]
#33> 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…
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 p…
Take a POS system. If at first you have a screen, keyboard and bar code scanner, you might think, "okay, what if we can't get this bar code scanner anymore?" so you modularize your HAL in a way that makes swapping out the bar code scanner easy.
However, if you decide that sales should walk around with tablets to enter transactions into and those go to the cloud for processing, well you just have to rewrite the whole thing.
The point is, you look for the things that could change right now. But you know that if too much changes, you have to redesign it. It is not about predicting the future. It is not about writing software that can absorb any change.