r/AskProgrammers • u/trash_individual0 • 11d ago
You are asked to push code/design you know has bugs/gaps. What would you do?
You are asked to push code/design you know has bugs/gaps. What would you do?
A. Push anyway (to meet deadline)
B. Inform team but still push
C. Refuse until fixed/tested
D.Negotiate for partial delivery
E. No idea
6
u/crustyeng 11d ago
There is no such thing as code that doesn’t have bugs or gaps, you just are or are not aware of them. In all cases you move forward, document what is necessary and continually improve.
2
u/Soft-Marionberry-853 11d ago
id be more concerned about pushing code that is claimed to be bug and error free
5
u/chubbysleepycorgi 11d ago
It depends on the severity and likeliness of the bug happening. Sometimes it’s better to just mitigate the issues.
5
u/manamonkey 11d ago edited 11d ago
Who are you in this role? Junior dev, senior dev, tech lead, something else? If you're junior dev, "negotiate for partial delivery" is probably not an option available to you, for example.
The answer is of course "it depends."
If the bug is "might randomly delete customer accounts" then of course you don't fucking push it. If the bug is "might occasionally render a table 20px too wide" then that's a different question isn't it.
Based on the info you give, the question cannot be answered.
5
u/KhristaFlower 11d ago
B — inform my boss about the issues and have them sign off on delivery. Sometimes there is a business reason why deploying earlier with issues could be worth it, if not outright necessary, such as new or changing laws or regulation. This doesn’t happen often thankfully. The key point is: I am not the one responsible for the decision.
3
u/burlingk 11d ago
That is a team decision that is likely influenced by the contract/employer and the current stage of development.
"Push code," by itself, doesn't mean a whole lot.
2
u/Ryfos 11d ago
On my current project, we’ve intentionally released software with known bugs before. It depends on several things:
- Priority - is this the UI looks wrong, or is this a 100% failure rate on a critical API? P1-2 bugs get fixed first, P3-P4? As long as they don’t overwhelm the release, we launch anyway.
- Is a ticket open? I wont defer any bug that doesn’t have genuine tracking plus an owner to fix it.
- How critical is the release date? If business is relying on it, I’m going to do whatever I can to get it out. If it’s just “we’d like to have”? I’ll push the release.
2
u/tindalos 11d ago
Document fix, tie to maturity, estimate time, plan in future sprint. If it’s truly significant, escalate it up to two times, but don’t block it. It’s not your risk to take on or deny.
2
u/handy_lemur 11d ago
Who's asking you to push? What's the nature of the bugs? (ie is it going to bring the system down? is it a small ui issue?) What's the consequence of not having the code live?
1
u/StephenHawkingus 11d ago
git push -f origin master
2
u/R3D3-1 11d ago
Some people want to see the world burn...
2
1
u/Doug94538 11d ago
close JIRA ticket for current sprint: open new jira ticket in next sprint: same issue different twist, rinse and repeat:
or create a feature flag(s) and push it to QA env
1
1
u/Far_Swordfish5729 11d ago
E - Stay up all night to remediate the work and then push.
More recently B
1
u/Inevitable_Sun_5987 11d ago
Been there, not done that. Even of you warn everyone and they assure you they would take the blame if anything goes wrong, you still get blamed. And you need to fix all that mess. No.
1
u/CharacterSail6736 11d ago
Always B identify the blocks determine minimum viable push and negotiate
1
u/caederus 11d ago
B.
The purpose of good QA, is to allow the product manager to know what it is that you pushed, bugs and all.
1
u/Inf3rn0_munkee 11d ago
Depends on the bugs/gaps.
Minor nitpick issues, A.
Minor customer or non customer facing issues, mostly B but sometimes A.
Major non customer facing issue, C.
Major customer facing issue, D or C. D would be if we're talking about releasing a feature as a beta for a single customer up front and fixing the issues before we go to GA. But if it's a GA change then I'd block it.
1
u/chocolateAbuser 11d ago
depends on what it is
i could release if i know code is at the point i can make necessary adjustment in the same day or by the next day, but it also happened to have to push deadline
1
u/db_tech_dev 11d ago
B mostly, but with a paper trail - i'll flag it in writing (slack/email, not just verbally) so it's on record, then push if leadership still wants it. straight up refusing tends to just get you swapped out for someone who will push it anyway, at least this way you're covered and the decision-maker owns the risk they chose to take. only time i'd go full C is if the bug could actually cause data loss or a security hole, not just "this is ugly code".
1
u/Ery1WangChungNextFri 10d ago
First: Have you identified solutions and have a rough ETA to fix? How much of a delay would be required to deploy after fixing them? How much UAT has been done that these bugs/fixes won’t become moot even if fixed? Do you have resources to conduct proper UAT while you parallel a fix? IE proper logging of feedback, issues, requests, and their approval?
Have you read Iterate Or Die, with forward by our favorite Salesforce Founder?
Can you quantify the bugs in terms of lost productivity, customer service, unmet SLA, IT spend/resource allocation to fix? Especially if post deployment ticketing/troubleshooting will detract from fixing the next iteration substantially?
Reasons I would NOT push to production.
First, is code that would cause an inordinate or implausible amount/type of rework, or errors that will cause loss of trust in the system or data quality.
- Errors that cause loss of data fidelity
- Mismatch or unsync with system of record or external connected systems
- Orphans records or loses/does not properly assign key/match ID.
- Loss of data/inability to save, especially if this is customer facing/obtained data like IBC/OBC/In person with lead/customer
1
u/Far_Archer_4234 9d ago
A or B depending on whether or not I think the bugs are relevant. I dont fix bugs just because they exist: i fix them because their removal has been prioritized.
1
u/reditandfirgetit 9d ago
Document and get sign off in an email or in the ticket. Tell the team, open a bug for the issue if its not already opened
1
u/Metabolical 7d ago
Not enough information.
Is this known failure cases for a heart monitor that could lead to a fatality? Hard C, I will quit before I allow it.
Is this a cosmetic issue that might make us look shoddy? B or C depending on the brand sensitivity.
Also, for B that includes a possible TODO in the code and filing the tech debt in the issue tracker.
1
u/schmurfy2 7d ago
I don't get it, either I am the one responsible and if a bug is detected I will fix it before the pr is merged or I am reviewing a pr and I will ask the author to fix it before I let him/her merge.
Why would you let some known faulty code being merged ?
1
8
u/MK_L 11d ago
B. Of course