Hacker News new | past | comments | ask | show | jobs | submit login

Conway'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.



No, 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.


Even 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 )


Yeah, 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.


No 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.


>If thing Y was remotely complicated and if the teams had a good working relationship why would they choose to duplicate their work.

So many reasons, but they usually boil down to simple self-importance.

Also, remember that it's harder to read code than to write it. Any non-trivial library or service is going to have a learning curve.

>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 ).

Everyone has their own opinion.

In a rigid structure, this perspective wouldn't work because your paycheck would be imperilled by it.

>The problem isn't people chose different tech stacks its they don't want to work together.

Sure, I agree. In a correctly organized structure, their incentives would change, and their behaviors would be more cooperative.

>If they did they would choose tech stacks and work practices that foster collaboration.

No, that's like saying if people wanted unity, they'd make choices everyone would agree on. Everyone wants unity. They just everyone to unite to their idea of what's important/right.

Management is all about crafting an environment and structure that causes people to work in a productive way. That could happen in this company, but it hasn't.


It sounds like the teams should be reorganized to match the desired software architecture. Conway's Law is bidirectional. :)


This. 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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: