4 ms·

All Conway’s Law means is that to build a system (from new components, anyway) that work really well together it is very helpful for the builders of those new c

All Conway’s Law means is that to build a system (from new components, anyway) that work really well together it is very helpful for the builders of those new components to communicate with each other during the process. This is a fine heuristic, but it can be interpreted in different ways as you see fit. For instance, since I advocate for professional testing (rather than amateur testing that Agilists prefer) I say, by Conway’s Law, that testers should be gathered together in one team, rather than scattered around in little Scrum teams. Testers benefit more by working together than they do by hanging around developers, since only coding testers really can deeply understand the devs and the code, and when they try they simply become junior developers and lose all the critical distance that makes independent testing effective. By Conway’s Law, the “Whole Team” approach really just coopts testing and isolates testers (like being the only sober guy at a party), and puts the tester under pressure to get along instead of critique the product. Fowler poo poohs the idea of independent testing in his article, but he is not a professional tester and I think he hasn’t thought this through. The couple of times I met him he was friendly and listened well, though.

kitd 4y ago
Note that Conway's law states that systems will be structured according to how humans communicate. Often, for dev teams, that aligns with how the APIs interact, but for, eg, testing teams, doc teams, devops, etc, that communication might be all the non-functional stuff that doesn't have to be in code per se but is still valid communication, and will still drive org structure per Conway. So I think your idea is still compatible with Conway.
q7xvh97o2pDhNrh 4y ago
> it is very helpful for the builders of those new components to communicate with each other during the process. IMHO, it's about communication and incentive structures. Each person is naturally going to optimize for the incentives of their local team, so the job of the organizational-designer is to align these incentive structures across teams. > since I advocate for professional testing (rather than amateur testing that Agilists prefer) ... Testers benefit more by working together than they do by hanging around developers, since only coding testers really can deeply understand the devs and the code, and when they try they simply become junior developers and lose all the critical distance that makes independent testing effective. This is really interesting to me, since I largely believe the opposite: Engineers should be writing their own tests, because otherwise they won't be incentivized to write good, clean, maintainable, testable code. Can you share more about your take on this? Sounds like you've probably had similar conversations before — any particular case studies or data you like to lean on?

kitd 4y ago

Note that Conway's law states that systems will be structured according to how humans communicate. Often, for dev teams, that aligns with how the APIs interact, but for, eg, testing teams, doc teams, devops, etc, that communication might be all the non-functional stuff that doesn't have to be in code per se but is still valid communication, and will still drive org structure per Conway. So I think your idea is still compatible with Conway.

q7xvh97o2pDhNrh 4y ago

> it is very helpful for the builders of those new components to communicate with each other during the process. IMHO, it's about communication and incentive structures. Each person is naturally going to optimize for the incentives of their local team, so the job of the organizational-designer is to align these incentive structures across teams. > since I advocate for professional testing (rather than amateur testing that Agilists prefer) ... Testers benefit more by working together than they do by hanging around developers, since only coding testers really can deeply understand the devs and the code, and when they try they simply become junior developers and lose all the critical distance that makes independent testing effective. This is really interesting to me, since I largely believe the opposite: Engineers should be writing their own tests, because otherwise they won't be incentivized to write good, clean, maintainable, testable code. Can you share more about your take on this? Sounds like you've probably had similar conversations before — any particular case studies or data you like to lean on?