1. Conway's Law
The video explains Conway’s Law as software structure mirroring how the team building it communicates. The speaker connects this to how frontend, backend, database and DevOps specialists organize and coordinate.
Hear it at 0:02 →Engineering video
0:52 · 12 August 2023
The video explains Conway’s Law as software structure mirroring how the team building it communicates. The speaker connects this to how frontend, backend, database and DevOps specialists organize and coordinate.
Hear it at 0:02 →several development mental model for out of 10 onways law. Originated in an article written by Melvin Conway in 1968, it states that the stature of your software system will tend to mimic the structure of your team. Better organization, better structure. If you look at software teams, they are usually built around the tinkle skills of each member. You have front end engineers, back end engineers, database admins, devops people.
So the software they build will reflect their communication structure. In a small team, this is not an issue. As people will still be able to communicate well and deliver. In a big team, having developers from different specializations and locations working on the same service will be problematic. Your software architecture must be aligned with the structure of your team. When you're making a tinkle decision, don't pay attention only to the tinkle side of it, but also on how the development team will organize around it to deliver.