Currently, I work in a company that divides the product into squads, and each squad is responsible for a different product (or software). The squad that I've been working takes care of a software that all other software use (It's a Payment Gateway), and every change that we do, we need to communicate to the other squads. With that in mind, I said to my product manager that this is a sign of a bad software, because the software's are hight coupled, and he said that I'm completely wrong, that communication is the key to the success.

I agree that communication is the key to success, but this doesn't change the fact that the software is poor because we have to warn everybody when we want to change something (I'm not talking about changing the API, but instead things that are internal)

What are your thoughts about that?

closed as primarily opinion-based by gnat, Greg Burghardt, Doc Brown, Robert Harvey, Thomas Junk Aug 25 '18 at 14:51

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    There's not enough evidence in your question to say one way or the other. There can be many causes of "over-communication," and your product manager is right to imply that what you interpret as over-communication might actually be reasonable, productive communication. – Robert Harvey Aug 24 '18 at 17:31
  • 3
    Do you "we have to warn everybody when we want to change something" because that's a rule given by management or because it breaks things for the other teams? – JimmyJames Aug 24 '18 at 18:10
  • 3
    @user91352: throwing the software away and rewrite it from scratch does not sound very constructive. Recommended reading: Joel Spolsky's great essay Things you should never do. – Doc Brown Aug 24 '18 at 19:15
  • 1
    Doc Brown is pointing out a common misconception, that developers believe a rewrite is quicker than working with the existing garbage code. It is true that many times the rewrite is never finished, due to underestimating the effort. On the other hand, if the existing system is not super complex fundamentally, sometimes a rewrite is faster. The only feasible rewrites are those that can be done incrementally. – Frank Hileman Aug 24 '18 at 23:51
  • 1
    @user91352 How does over communication help to avoid API breakage? – Goyo Aug 25 '18 at 13:57

Based on your description of the issue: "even a slight change in the internal code can compromise the API, and therefore can break software that is using it.", it sounds like your API suffers from one or more 'leaky abstractions'. Typically the way this happens is when your API is simply a pass-through to underlying data structures. For example, a common problem is that people use an ORM to generate an anemic domain model and then use that to generate a web service layer. It's quick and easy and you don't actually need to write any code but it means that any change to the database model manifests itself as a change to the API.

As you state: communication is not a bad thing in itself but it's bad to need to use communication to make up for an unstable API. It's a solution to a symptom of the problem.

If your manager doesn't understand this, he is likely not technical or doesn't understand software architecture at the level that this is being done at. I guess I'm saying: yes, this can be indicative of bad API design. The point of abstractions is to limit the coupling to a small surface area. That allows your teams to work more efficiently since they need not be concerned with every aspect of what every other team is doing. The development of microservices was driven by just this problem. For a large technology organization, the cost of having all teams coordinate their efforts on a constant basis is unsustainable. If you read between the lines, you will see that this approach is driven more by organizational/management problems than truly technical ones.

Unfortunately, you are unlikely be able to solve this problem unless you are a lead architect or developer. Your manager might be able to affect some improvements if he understands the problem. It might be that he does but accepts that for the time being you will need to continue to communicate in order to work around this flaw in the architecture in order to meet a timeline.


If your clients (yes, those using your service are clients, even though they are in the same company), depend on your services interna, something is wrong.

At least one of these hold:

  1. Your interface is not properly documented.
  2. Your interface does a poor job at encapsulation and abstraction.
  3. Your clients are programming using trial and error.

The way forward is thus slow and fraught with peril:

  1. Properly define and document your current interface.
  2. Where needed, phase out parts of the current interface and replace it with a better engineered one.
  3. Push for getting your clients better educated somehow.

The talking points for management are money (saved due to knowing instead of guessing after gathering evidence), money (saved due to better efficiency and ergonomy) and, you guessed it, money (saved due to your co-workers knowing what they are doing).

Hopefully, after a short time your clients can from then on program to a reasonably stable interface, reducing the need to closely coordinate all changes, and actually know (how) to do so.

Of course, it might be that the business-rules of your service change due to legislation, management fiat, or whatever. In those cases where you cannot simply abstract it away, think about versioning at least.


When is communication over-communication ?

Strong communication could indeed be a symptom that something is wrong, for example that a component was split into parts but shouldn't have been. But it could as well be the evidence that teams that have something in common work together very effectively.

So how to make the difference ? It's not a question of quantity, because IMHO, the most frequent case is absence of communication: teams work in silos thinking they live on an island. This always result in misunderstandings, unexpected surprise (what ? they changed the API two weeks before our release ?) and frustration.

Self-introspection questions: what's the quality of the communication ? Is it useful ? Is it constructive ? What's your negative feeling about it ? Is this negative opinion shared by your teammates ? And by the members of the other team ? Why do you think "it's too much" ?

Structure of the business domains

If there is some common functionality or domain parts (as it seems for your gateway), what would be the best solution according to you: repeat/redevelop/reinvent a new gateway for each product or isolating the functionality ?

So maybe the shared component is exactly the architecture needed and your team is key to the success of all the others. But if the other team all rely on it, isn't it normal that you involve them as stakeholders in the decision ? After all, if you were in an application team, you'd have frequent meetings with your customers for gathering the requirements, demo new user stories, and collect their impressions !

Self-introspection questions: are the communication useful, i.e. about requirements and interdependencies ? Or is your team not daring to take some decisions on its own and over-involve the stakeholders in the teams decisions ?

Quality ?

Bad quality, for example if there are too much bugs delivered, could cause extra-inquiries from the other teams. This would be some kind of communication that is symptom of bad software.

Bad design as well. If your component is not SOLID, you and your customer will have unnecessary discussion, due for example to a tight coupling that could be avoided with interface segregation and dependency inversion.

Missing information could also be artificially cause over-communication. A good reference documentation (attention: do not over-document ;-) ) and some release notes can really help to avoid unnecessary discussions.

Self-introspection questions: are you proud of what you deliver ? And would you enjoy consuming the gateway if you were in another team ?


With the little information I have, it's difficult to give an objective opinion on what's happening.

But over-communication is not necessarily a software design issue. It can be a problem with the communication and collaboration practices. Fortunately, these can very well be improved if there is awareness.

  • Interfaces and dependency inversion are unlikely to solve any coupling problems, unless the problem is decoupling from a third party, and the interfaces can be frozen forever. The best way to decouple software components is to entirely remove dependencies, using layering or other techniques so the calls and type references are removed. – Frank Hileman Aug 24 '18 at 23:42
  • @FrankHileman Thanks for the observation. But now I'm in doubt: Don't fat interface lead to inadvertant coupling because of a lack of separation of concerns (a topic that ISP addresses) ? And isn't the intent of DI to achieve a loose coupling ? In addition, I'm not sure that layers alone could eliminate coupling: in fact Palermo and Cockburn both came to the opposite conclusion, which lead them to conceive the DI based hexagonal and onion architectures in order to get a looser coupling between layers. – Christophe Aug 25 '18 at 0:15
  • Intuitively, swapping a call to an interface, that is implemented by a class, for a call directly to the class (or base class), does nothing to change the coupling, which is from one object to another. This is more apparent when any changes to the member signatures in the class require changes to the interface. Fortunately, our intuition is correct. Authors claiming this provides decoupling are promoting one size fits all solutions that take no account of the specific problems in any application. – Frank Hileman Aug 28 '18 at 20:34
  • @FrankHileman would you mind, if I prefer not to continue an opinion/intuition based debate about whether to be SOLID or not? The main point in my answer is about communication, and the fact that the quantity of communication is not necessarily related to bad software. Of course, I don't know the details, so my "introspection questions" aim to help OP make a more objective self-diagnosis (because introducing the question with "over-communication" shows he made a subjective judgement). I'd like to invite you to make your own answer, if you have any other ideas related to this topic. – Christophe Aug 28 '18 at 21:22
  • There are enough answers here already. I do attack any defense of SOLID, as I consider it to be one of the greater contributors to unnecessary complexity in software today. – Frank Hileman Aug 28 '18 at 23:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.