You come across an issue that just ain't getting fixed in a short amount of time? What goes through your head, what do you begin to think about?
For further actions, you may consider blocking this person and/or reporting abuse
You come across an issue that just ain't getting fixed in a short amount of time? What goes through your head, what do you begin to think about?
For further actions, you may consider blocking this person and/or reporting abuse
Jagan kumar -
Pranav Bakare -
Vinod Kumar -
Shafayet Hossain -
Top comments (24)
redo the whole project lol
not necessarily what exactly needs to happen to fix it, but how can the whole team be involved in fixing it so that it doesn't happen again. With everyone getting involved it:
if the bug is hairy as u say i will start with roots and re-build the whole code without rewriting it just double check everything and i hope u were using any kind of version control just print everything
My thoughts turn to mitigation and isolation.
First things first, how can I make it livable for however long I have to live with it? Can I put a cron in to restart a troublesome service? Can I add more retries to talk to a box with a bad network? Can I wrap a bad library with something that makes it less bad?
Second, how can I contain the problem so when I want to fix it properly I can do it quickly and without hurting the rest of the system? Interfaces, facades, etc.
Finally, I like to document how much the issue hurts the team in terms of lost productivity and hours spent messing with it - never hurts to have ammo to convince stakeholders and supervisors that we should make a persistent problem a priority.
The greatest part is the users might get used to it and fixing the bug may create churn 😁😆
“It's not a bug, it's a feature (now)!“ :D
Given that I have the privilege of just hacking and making it up as I go, this is half my day I swear.
First thing I usually think about it if the code is designed correctly. There is usually a design flaw that causes those bugs. At least in my experience. Lay out the steps you need to do in the simplest form and see if there is a better way to do it.
Project stopping bug early in a development? Start from nothing and see where things went wrong.
Project stopping bug later in development? Start breaking the data flow apart to see where things go wrong.
Anything else gets prioritized based on how critical (work around available?), and how burnt out I am dealing with that particular issue.
I guess this is where IDE capabilities are the most helpful because nobody can debug like the IDE debugger, through breakpoints and narrowing down the function or variables which are responsible for doing something but are messing up big time.
How long has this bug existed, and is it generating issues for customers?
Can I present a work-around approach to the team to mitigate the bug's impact?
Can I make a business case to management/client to allocate resources to fix this bug? What are the costs to repair the bug? What are the costs to ignore the bug?
First, I try to log every step of the buggy method into a log file (especially when it is on a production server).
Then I take an abstract look at the method design, to make sure I don't have any design gotchas.
Then, I retrace the call and check the platform/plugin details (if for example it is a plugin that is used in a mobile app).
I just work the problem in the Agile way with a combination of spikes and user stories, maybe contained within an epic if it's that big and hairy.
I've got one right now that I'm working on that's been a bit tough to define. I've been working this spike for the entirety of the current sprint. Users tell me it's a big problem but can't really give me a clear description of what is needed to correct the issue. It's probably part business process/policy with software changes to match the desired policy. Getting to the desired policy though is where there's a lack of agreement. Until product owners agree, it will be difficult to move forward.
In other cases, it's been a bit easier but getting to the root cause (to use one of my least favorite buzz words) of the problem is the first thing. I've usually found that it goes back to data so that tends to be the first place I look. For example, a column in a table can be null but the code expects it not to ever be null. If good tests are in place, this isn't too difficult usually. But, when working with legacy code, there may not be tests available so it requires really digging into code that might have been written 10+ years ago.