3 ms·
Everyone should know about Conway's Law [0], especially in the age of microservices. I currently work in an environment where there is virtually no central tec
by cookiecaper 10y ago
Everyone should know about Conway's Law [0], especially in the age of microservices.
I currently work in an environment where there is virtually no central technical management. There are groups of 2-4 developers who roam around their department's problem space, making whatever choices they want.
If someone doesn't like the interface on one microservice, they fork the code and make a new one. This leads to 5 microservices that accomplish the same thing, and 5x the maintenance burden whenever something changes. I've derisively called these "nanoservices", but I need a more offensive term.
People intentionally choose techs that no one else in the company has used, trying to cement their position and hedge up potential competition or unwelcome cooperation. They also select technology for the best PR effect, being able to say "We're being like Google today". The result is a whole mess of different stuff running throughout production, each needing its own backup system, etc., which, to be honest, does not always get installed.
It's a disaster.
The author's contention is that giving more choice to teams is better because it makes them feel more ownership in their product. That's fine, but do recognize that this is a psychological solution to a management problem. The job of the manager is to actively control the psychology of employees and the structure of the organization such that employees are happy to do things that lead to cooperation, not to allow employees to always get their way.
Without a central coordinating force and everyone's acknowledgement that some compromise and sacrifice is necessary, everything falls apart quickly.
[0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- dkhenry 10y agoConway's Law in your environment should probably be interpreted that you have a team that can't talk or work together at all. It has nothing to do with what technical choices they are making, even if you imposed a rigid technical structure you would still have divergent nanoservices because your team can't communicate.
- cookiecaper 10y agoNo, it's not that they're incapable of working together. It's that they have no incentive to do so. They can do whatever they want now and improve their own positions by so doing, so why shouldn't they? Normally, people don't do this a) because they don't want to be required to deal with the cruft or b) because they believe someone will observe their bad behavior and stop it. They don't really have to deal with the cruft, and it's clear now that no one in this organization will hold them accountable, so why should they waste time and energy trying to build a consistent platform? re: Conway's Law, the organization's communication mechanisms are loose and ad-hoc; there is no central coordination. Consequently, the software is coordinated on a loose, ad-hoc basis between small teams. The same featureset will be implemented 4 times by 4 different teams, not because they can't talk (there is an office where most people hang out together all day, and people do generally keep an awareness of what the other group is working on), but because they'd rather just do it the way they want to do it. It's not that no one ever ends up sharing anything. It's just that instead of having a discussion and making consistent decisions about the platform, they just do what they want, because they can.
- cpeterso 10y agoIt sounds like the teams should be reorganized to match the desired software architecture. Conway's Law is bidirectional. :)
- beastcoast 10y agoThis. Amazon has embraced SOA for a long time, and the organization is literally built around independent teams owning services. As the owner of a service, you have a charter, and other teams that want to use your service are encouraged to use your service so long as it fits your charter.
- dkhenry 10y agoEven if you imposed a singular stack, I could just do it my way at whatever level you started to let me make decisions. All you end up doing is adding overhead to your basic problem which is your teams are not communicating, fix that problem and your tech stack becomes irreverent. People will start to talk and start to organize into best practices simply because its easier ( why reinvent the wheel if Jim in accounting already did it and I can just use his stuff )
- cookiecaper 10y agoYeah, but again, the people aren't necessarily mean-spirited or hostile. They'd cooperate more if the structure to affect that existed. You're acting like they don't talk. They do talk, they just don't care. They know that guy x is making thing y, but they don't want to do it in the language/platform/framework/whatever he's using, so they make their own thing y. Structure needs to be in place to make cooperation happen.
- dkhenry 10y agoNo it doesn't. If thing Y was remotely complicated and if the teams had a good working relationship why would they choose to duplicate their work. Even if it was in a completely different tech stack you would still try to leverage someone else's work and there are plenty of ways to do that in almost any situation across most technologies. Also even if a rigid structure existed I can still not use your thing Y most likely because I don't respect your work and I would implement thing Y differently ( and in my opinion better ). Then you get thing Y and thing Y+1. The problem isn't people chose different tech stacks its they don't want to work together. If they did they would choose tech stacks and work practices that foster collaboration.