have more components than people (an order of magnitude or so?)
avoid “utils” and other catch-all dumping grounds
have your components be searchable
you’re still going to get libraries/tools/etc. that follow org structure, but you can get a lot outside of that structure too, and that’ll be more reusable
Yes. This goes beyond software, too. The way to exploit Conway’s law is to shape the organisation after the system you desire to build. This implies things like smaller, cross-functional teams* with greater responsibility (in order to get less coupling between system components). That way you maximise communication efficiency.
* Lean people would advocate that the team should be co-located too. The idealist in me still clings to the Microsoft research that showed org chart distance mattered orders of magnitude more than physical distance.
I’m missing Lehman’s laws of software evolution, at least the first two:
I LOLed at that one
re: conway’s law
i think you can work around this to some extent:
you’re still going to get libraries/tools/etc. that follow org structure, but you can get a lot outside of that structure too, and that’ll be more reusable
Why work around it? Isn’t the purpose of Conway’s Law to accept the inevitable rather than fight it?
FWIW I’ve worked in an environment that follows your suggestions and it still followed Conway’s Law.
Yes. This goes beyond software, too. The way to exploit Conway’s law is to shape the organisation after the system you desire to build. This implies things like smaller, cross-functional teams* with greater responsibility (in order to get less coupling between system components). That way you maximise communication efficiency.
* Lean people would advocate that the team should be co-located too. The idealist in me still clings to the Microsoft research that showed org chart distance mattered orders of magnitude more than physical distance.