Discovering a Design Flaw Right Before a Project Deadline: How Do You Respond?

Your team's project is close to its due date when you discover that a design decision made earlier in the project is flawed. What do you do? This scenario came up as a single-choice situational question in an online assessment; the answer options were not reported. Answer it in your own words: explain how you would decide what to do, what you would actually do, and, if you have one, support it with a real example from your own work. ```hint Size the problem first Before choosing between the deadline and the fix, ask what would actually go wrong if the project shipped with the flaw, and for whom. ``` ```hint Think about who needs to know Consider who depends on the due date, who can change it, and how much notice they would need to plan around a change. ``` ### Clarifying Questions - What kind of flaw is it: does it produce wrong results, lose data or open a security hole, or does it mainly hurt performance, scalability or how easy the code will be to change later? - Is the due date a hard external commitment, such as a launch, a customer contract or another team's dependency, or an internal target? - How much has already been built on the flawed design, and is there a narrow fix or a mitigation that could contain the problem until after the deadline? - Was it your design, a design approved in a review, or one you inherited from someone else? - Who can move the date or cut scope: you, your lead, or a product owner? ### What a Strong Answer Covers - Confirming the flaw and judging its severity and blast radius with evidence before deciding anything - Concrete options (fixing now and moving the date, shipping with a mitigation and a scheduled fix, cutting the affected scope) and the risk of each, including the risk of a late, rushed fix - Raising the issue promptly and openly with the people who own the date, with a recommendation rather than just the problem - Ownership of the mistake without blame, and follow-through so that a deferred fix actually happens - A process lesson that would catch a similar flaw earlier next time ### Follow-up Questions - Your manager wants to ship on time, but you believe the flaw can corrupt user data. What do you do? - The flaw is in a part another engineer designed, and they do not agree that it is a problem. How do you handle it? - You decided to ship with a workaround. How do you make sure the real fix actually happens afterwards? - Looking back, how could the design review have caught this flaw earlier?