That makes no sense. If you join b’ and b’’ into b then the external interface of b is the union of the external interfaces of b’ and b’'. The risk of conflicts between those two interfaces is minimal in the situation they described so no need for namespacing.
I expected the argument to be based on total effort to split then join the internal code compared to the context switching cost of splitting and then splitting again (with an appeal to agile vs waterfall). But this argument feels like they were either dealing with a language/stack with a broken module system that lacks an explicit separation of internal vs exposed or were just joining things strangely.
Expressing a general rule based solely on a specific situation is a disservice (irony intended).
I agree with the author overall, and I think it can be more straightforwardly stated. IMO it’s the idea that wrong abstractions are even worse than other ills like duplication or god classes/modules. It’s also reminiscent of “modules should be deep”.
That makes no sense. If you join b’ and b’’ into b then the external interface of b is the union of the external interfaces of b’ and b’'. The risk of conflicts between those two interfaces is minimal in the situation they described so no need for namespacing.
I expected the argument to be based on total effort to split then join the internal code compared to the context switching cost of splitting and then splitting again (with an appeal to agile vs waterfall). But this argument feels like they were either dealing with a language/stack with a broken module system that lacks an explicit separation of internal vs exposed or were just joining things strangely.
Expressing a general rule based solely on a specific situation is a disservice (irony intended).
I agree with the author overall, and I think it can be more straightforwardly stated. IMO it’s the idea that wrong abstractions are even worse than other ills like duplication or god classes/modules. It’s also reminiscent of “modules should be deep”.