7 ms·

How is people not talking to each other an improvement?

jcadam 8y ago
Well, from a systems standpoint, it means a given "problem" is isolated to a single service, and is therefore not impacting the other services or interrupting the work of the other teams. But culturally, it would be nice if people helped each other out from time to time...
- marcosdumay 8y ago
  That's only true if any given problem is isolated on a single service, because while you are making intra-service problems much cheaper and faster to fix, you are also making inter-service problems almost impossible to fix.
  - jcadam 8y ago
    Good point. I've seen situations where nobody would take ownership of a bug and fix it - you just had teams pointing fingers at each other...
    - BerislavLopac 8y ago
      This is precisely a symptom of unclear ownership responsibilities.
      - AnimalMuppet 8y ago
        No, it can be an issue of it being unclear in which component the bug actually is.
        BerislavLopac 8y ago
        Which is a clear sign that your components are not sufficiently separate.
        AnimalMuppet 8y ago
        Um, no. The real world is not that simple. It would be nice if it were. Or perhaps your statement is correct, but in the real world components are never sufficiently separate. So, while your statement may be correct by definition, it is not useful.
        james_s_tayler 8y ago
        I think you really nailed it with this one. I can imagine there being a normal distribution of 'separateness' of software and the rare top tail-end of the distribution gets it perfectly right, most are in the middle somewhere between 'service oriented architecture' and 'ball of mud' and some are just at plain ball of mud.
        BerislavLopac 8y ago
        You are misreading my words.
        AnimalMuppet 8y ago
        Perhaps so. Would you care to explain? Your statement here doesn't give me much to go on.
        BerislavLopac 8y ago
        Well I meant it quite literally: if it is not clear which component has the bug, the components are not separate enough. You also say: > in the real world components are never sufficiently separate But the separation of components is not an issue of "real world", it is a function of design and implementation. It is absolutely to the developers how independently the components will be implemented; if there is no way to test them in isolation, then they are not really separate components. Take this website, and your browser, as an example. They are obviously connected, as you're using the latter to access the former, but they are completely independent: you can access other pages with the browser, and you can use other methods (other browsers, or curl, or Postman etc) to access this page. Each can be tested separately, and even when they are used in conjunction they don't directly depend on each other, but rather on a set of standards (HTTP, HTML, CSS etc) understood by both.
vibrato 8y ago
Dunbar's number. As humans, we only have room for so many relationships.
BerislavLopac 8y ago
Oh, it is definitely a problem from a social/cultural standpoint. But from the point of software architecture (and, therefore, development organisation), too much (or even any) communication between teams working on discreet, separate units can become detrimental. It is perfectly fine that the people communicate, and even helping each other to improve tech skill should be encouraged; however, decisions about their respective products should be contained within each team, with clearly defined interfaces and usage documentation.
- badfrog 8y ago
  > decisions about their respective products should be contained within each team, with clearly defined interfaces and usage documentation. In order to make those decisions and define the interfaces, you need to know a lot about how your software is going to be used. That will be much easier if you have good communication with the other teams and understand their goals and motivations.
  - BerislavLopac 8y ago
    I disagree. In my experience, direct coordination on interfaces tends to create unnecessary special cases (hey, can you add this field to your API, just for us?) which add complexity and make maintenance more difficult down the line. The main advantage of distributed system, and particularly microservices, is the ability to have each system completely independent: individual components can be written in different languages, running on different platforms and use completely independent internal components. Basically, it is just like using an external library, component or service: the authors provide documentation and interfaces, and you should be able to expect it to behave as advertised.
    - badfrog 8y ago
      > In my experience, direct coordination on interfaces tends to create unnecessary special cases (hey, can you add this field to your API, just for us?) which add complexity and make maintenance more difficult down the line. If you just implement all requests directly, you're for sure going to end up with a horrible interface. You should approach API design the same way that UX/PM approaches UI and feature design: take the time to understand _why_ your partner teams/engineers are requesting certain changes and figure out the right interface to address their problems.
tonyedgecombe 8y ago
Presumably if you don't like other people then it's an improvement. At a guess I'd say that covers about quarter of our industry.
- badfrog 8y ago
  Probably we can agree that a company will be more productive if the engineers are learning from each other and generating ideas together? So if you've got a team of engineers who don't like working with people, it's probably in the company's best interest to set up a structure that explicitly encourages more communication.

Well, from a systems standpoint, it means a given "problem" is isolated to a single service, and is therefore not impacting the other services or interrupting the work of the other teams. But culturally, it would be nice if people helped each other out from time to time...

marcosdumay 8y ago
That's only true if any given problem is isolated on a single service, because while you are making intra-service problems much cheaper and faster to fix, you are also making inter-service problems almost impossible to fix.
- jcadam 8y ago
  Good point. I've seen situations where nobody would take ownership of a bug and fix it - you just had teams pointing fingers at each other...
  - BerislavLopac 8y ago
    This is precisely a symptom of unclear ownership responsibilities.
    - AnimalMuppet 8y ago
      No, it can be an issue of it being unclear in which component the bug actually is.
      - BerislavLopac 8y ago
        Which is a clear sign that your components are not sufficiently separate.
        AnimalMuppet 8y ago
        Um, no. The real world is not that simple. It would be nice if it were. Or perhaps your statement is correct, but in the real world components are never sufficiently separate. So, while your statement may be correct by definition, it is not useful.
        james_s_tayler 8y ago
        I think you really nailed it with this one. I can imagine there being a normal distribution of 'separateness' of software and the rare top tail-end of the distribution gets it perfectly right, most are in the middle somewhere between 'service oriented architecture' and 'ball of mud' and some are just at plain ball of mud.
        BerislavLopac 8y ago
        You are misreading my words.
        AnimalMuppet 8y ago
        Perhaps so. Would you care to explain? Your statement here doesn't give me much to go on.
        BerislavLopac 8y ago
        Well I meant it quite literally: if it is not clear which component has the bug, the components are not separate enough. You also say: > in the real world components are never sufficiently separate But the separation of components is not an issue of "real world", it is a function of design and implementation. It is absolutely to the developers how independently the components will be implemented; if there is no way to test them in isolation, then they are not really separate components. Take this website, and your browser, as an example. They are obviously connected, as you're using the latter to access the former, but they are completely independent: you can access other pages with the browser, and you can use other methods (other browsers, or curl, or Postman etc) to access this page. Each can be tested separately, and even when they are used in conjunction they don't directly depend on each other, but rather on a set of standards (HTTP, HTML, CSS etc) understood by both.

vibrato 8y ago

Dunbar's number. As humans, we only have room for so many relationships.

BerislavLopac 8y ago

Oh, it is definitely a problem from a social/cultural standpoint. But from the point of software architecture (and, therefore, development organisation), too much (or even any) communication between teams working on discreet, separate units can become detrimental. It is perfectly fine that the people communicate, and even helping each other to improve tech skill should be encouraged; however, decisions about their respective products should be contained within each team, with clearly defined interfaces and usage documentation.

badfrog 8y ago
> decisions about their respective products should be contained within each team, with clearly defined interfaces and usage documentation. In order to make those decisions and define the interfaces, you need to know a lot about how your software is going to be used. That will be much easier if you have good communication with the other teams and understand their goals and motivations.
- BerislavLopac 8y ago
  I disagree. In my experience, direct coordination on interfaces tends to create unnecessary special cases (hey, can you add this field to your API, just for us?) which add complexity and make maintenance more difficult down the line. The main advantage of distributed system, and particularly microservices, is the ability to have each system completely independent: individual components can be written in different languages, running on different platforms and use completely independent internal components. Basically, it is just like using an external library, component or service: the authors provide documentation and interfaces, and you should be able to expect it to behave as advertised.
  - badfrog 8y ago
    > In my experience, direct coordination on interfaces tends to create unnecessary special cases (hey, can you add this field to your API, just for us?) which add complexity and make maintenance more difficult down the line. If you just implement all requests directly, you're for sure going to end up with a horrible interface. You should approach API design the same way that UX/PM approaches UI and feature design: take the time to understand _why_ your partner teams/engineers are requesting certain changes and figure out the right interface to address their problems.

tonyedgecombe 8y ago

Presumably if you don't like other people then it's an improvement. At a guess I'd say that covers about quarter of our industry.

badfrog 8y ago
Probably we can agree that a company will be more productive if the engineers are learning from each other and generating ideas together? So if you've got a team of engineers who don't like working with people, it's probably in the company's best interest to set up a structure that explicitly encourages more communication.