On Conway's Law
Conway's Law, observing that a software system's design mirrors the communication structure of the organisation that built it, is overlooked in both academia and industry.
It suggests that to build good software, one must first be concerned with the collaboration structure of people building the software.
A consequence of Conway's Law is that one can infer the shape of a company's hierarchy by studying the source code. There are some obvious ideas here: packages and modules tend to be organized such that only one team works on a single package/module.
What could be interesting is to look at the communication between package/modules. Perhaps dysfunction between real humans would manifest as dysfunction in the source code too? e.g. bad or awkward API design caused by miscommunication, wrong assumptions, or frequently changing requirements. If so, one could try to detect poor communication patterns through program analysis. We could also do this the opposite direction, discover code that are likely to be buggy caused by the interaction of software modules developed by teams known to have communication problems.
Companies frequently panic when they discover that their "engineers" are making poor choices developing the software system. This is usually followed by many reactive, ad-hoc, overweight middle-manager-style decisions such as the introduction of more checks during CI, better development tools, checklists, 'raising the bar' when hiring new engineers. Worse still, they may hire consultants or form teams/committees to 'study' the issue. It's quite possible that a practical solution to the problem is to simply fix the dysfunction in communication patterns between teams.
- 9 toasts