Hacker News new | ask | show | jobs
by js8 1939 days ago
Is following Conway's law a bad thing, though? If the module is written/maintained by a single person, it seems to be more efficient and clear (of course subject to skill limitations of that particular human). What realistic alternative is there to Conway's law? Design by committee?

Conway's law might as well be, like democracy, the best of all the bad worlds.

2 comments

Specifically in the context of modules, I think it is a bad thing. It's hard to describe because I do it quite intuitively, but (very broadly) the way I find module boundaries is by trying to find the minimal interface for the maximal amount of code. For me, this usually revolves around some kind of data structure.

Importantly, this is completely independent of team structure. The boundaries between teams are not necessarily the minimal interface.

Are the modules you're thinking of heavily shared/shaped by the needs of others? I think it's fair to say that there are more influences than just communication patterns on the design of software. For instance, there's can be a different set of concerns/pressures on developers of open source libraries than on time-sensitive and closely coordinated projects within a company.
> The boundaries between teams are not necessarily the minimal interface.

No, but they are the inevitable interface.

>Is following Conway's law a bad thing, though

Is following the second law of thermodynamics a bad thing? I say so jokingly because thermo is a little more rigid, but I still think it's futile to fight Conway. After all, if you change your org structure to try to beat it, you're actually proving it.

It's not something to beat as much as it's something to inform decisions. Code should be architected with knowledge of how the organization is broken up, and orgs should be structured with knowledge of how that affects the technical side.

I guess all this is to agree with you and say...if breaking up modules in a certain way for small teams is effective for your organization, then it makes sense to do it.

To add to that, I think the biggest thing to take away from Conway's law is that splitting teams of developers becomes a technical problem. If your goal is to efficiently build a product, technical expertise needs to go into that decision.

This is why I say Conway's law is a bad thing for modules (regardless of how inevitable it is): technical considerations are often not taken into account, and technical design is ossified by team structure.