Is over communication a sign of bad software sometimes? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

Improve this question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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 ?

Conclusions

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.