Imagine a situation: the deadline is burning, and you have a choice — make a quick decision or rework the architecture, but spend twice as much time on it. What would you do? Have you had a similar experience?

In a situation with a tight deadline, the choice between a quick fix and reworking the architecture depends on the context and consequences.

If a quick solution allows completing the task on time and does not lead to serious problems in the future (for example, technical debt, support difficulties), then it should be chosen to avoid missing deadlines.

However, if architectural changes are critical for stability, scalability, or security, and a quick fix could lead to serious issues, it is better to allocate time for rework.

In my experience, there have been cases where I chose a quick solution for an urgent demo or prototype, and then planned refactoring. In other cases, when the project was long-term, I persuaded the team to allocate time for architecture to avoid future problems.

Important:

• Assess the risks and consequences of each option.
• Discuss with the team and stakeholders.
• If possible, break the task into stages: first a quick fix, then improvements.

This approach helps balance quality and deadlines.