Disappoint Now or Disappoint Later?

The other day I was remembering a time when I had to bring together more than five teams from my company, acting as a Staff Engineer, to decide on a transactional data point that hadn't been defined until then. The meeting had over 30 people.

To give you some technical context: all these teams would use a centralized transaction platform. These transactions had an identifier that was generated at some point during the sale. In the proposed architecture, multiple services would interact with the same transaction at different states. In other words, everyone needed to know about this transaction somehow. We needed to decide how this identifier would be formed based on the transaction data so we could share this state through a contract, not through global storage.

The issue was that it was already a bit late in the project to be discussing this. The project was already in development. This caused some panic among the stakeholders. But the truth is, this taught me a great lesson about accountability.

Even late in a project, we can come across definitions that were overlooked. This can happen. It's a risk. But it's not the end of the world. We reached a decision in that meeting, aligning multiple teams and adjusting the final integration. Raising this issue prevented massive rework, production failures, data inconsistency, among other potential catastrophes.

Some people are hesitant to say that deadlines are tight or that there are technical gaps that were filled in late. But what's better? Disappoint now or disappoint later?

Don't be afraid to raise your hand and say that something is wrong. It's your role as a professional and software engineer. Even if it turns out not to be a problem, at least you tried to foresee something important. And if it is a problem, you just had a major breakthrough.