[_0w8t]

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.

[lkxijlewlf]

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.

[Jtsummers]

> 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.

[_0w8t]

My experience is that anticipating future requirement changes do not work in general. So do not reflect in the design including the design of module boundaries the current assumptions about the future. Focus instead on other criteria, like reducing complexity or making the design more transparent.

[User23]

I think I get what you're saying and there's merit to it. However, it appears to me that you are arguing against something the submission doesn't say. If I were you I would reread it carefully and without prejudice, because based on your comments here I believe that you would enjoy learning the concepts it's presenting.

[_0w8t]

I did read the article. My reply was about its conclusion. The article itself advocated a toolbox approach of creating useful tools first that could be written and tested independently and then assembling the application from those. But this has little to do with anticipating future changes, more about of flexibility of assembling the application itself. I.e. the conclusion was not warranted.