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
Read next
What I learned in 6 months of working on a CodeGen dev tool GPT Pilot
zvone187 -
Music Monday — What are you listening to? (Funk, Soul, Disco, & Reggae Edition)
Michael Tharrington -
Why YouTube Never Runs Out of Storage? It's NOT just CLOUD!
Ujjawal Tyagi -
Property based testing in Go
Harutyun Mardirossian -
Latest comments (24)
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.
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).
Its a little open ended. There are different types of bugs. There are bugs where you see where the problem is but don't know why. There are bugs where you don't even know where the problem is. Assuming that your code is well designed you will know where the problem is. Get second pair of eyes on it, pair programming always helps. If the code is spaghetti, this is a perfect opportunity to re-factor. If we are stuck for a while, take breaks, switch to doing something else. Get an ice cream :)
what do I begin to think about?
How did i just ____ myself?
Try to convince the business side to promote it to a feature.
If they say no I can throw the bomb "refactoring".
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.
In a different environment!
This is how we do it:
a) Try to find a workaround, and mark the workaround with "FIXME".
b) Invest one week per quarter to fix all the FIXMEs (whole team - fixmekathon).
And a general thought: If anything (feature, issue, ...) seems to take "very long": invest 15% of "very long" into thinking about the problem and sketching solutions. This will mostly reduce "very long" and result in better solutions.
I document it and break it down into steps.
Sometimes there's a part of your code which works but nobody remembers how, something legacy that nobody wants to touch for fear of breaking it.
Fear of fragility is a major reason these bugs go on so long, so periodically revisiting your code or getting another set of eyes on it will go a long way to preventing these sorts of things in the first place.
I have just finished going through this process for an authentication system on a big, sprawling project which was tripping up in various ways but seemed too big to replace. It took a while, and it took me working on a separate branch and having maintenance tickets deflected to other developers for longer than the client wanted, but it's all better now. I can pat it on the head and give it a lollipop.
Incidentally, this is why my Mac is so out of date. It tells me it needs to reboot every day and I deny it because I have no confidence it'll come back up. MacOS has tricked me too many times. At some point I'll wipe it and start from scratch, or get a replacement. But the OS is so fragile that I avoid going anywhere near updates and patches.
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.
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.
Usually if a bug is taking long to trace, then its better to sleep over it. Most of the times its just a wrong approach one is taking in tracing it. Also its better to take such bugs at the end, if they aren't show stoppers, to save and spend valuable time on being actually productive.
It's a feature leave it like that 😂😂
Can I add telemetry data or traces? Keep gathering data, which over time will give me enough information to formulate a hypothesis. Hopefully.
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?