Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We stopped roadmap work for a week and fixed bugs

lalitm.com

Post reply on HN
Print view View original

211–220 of 356 posts

Re: We stopped roadmap work for a week and fixed bugs

#211

Post by Mtinie »

fransje26 wrote: post #121
arkh wrote: post #107

Earlier quoted context omitted.

> Sometimes, a "bug" can be caused by nasty architecture with intertwined hacks The joys of enterprise software. When searching for the cause of a bug let you discover multiple "forgotten" servers, ETL jobs, crons all interacting together. And no one knows why they do what they do how they do. Because they've gone away many years ago.

> searching for the cause of a bug let you discover multiple "forgotten" servers, ETL jobs, crons all interacting together. And no one knows why they do [..] And then comes the "beginner's" mistake. They don't seem to be doing anything. Let's remove them, what could possibly go wrong?

If it’s done in a controlled manner with the ability to revert quickly, you’ve just instituted a “scream test[0].”

____

[0] https://open.substack.com/pub/lunduke/p/the-scream-test

(Obviously not the first description of the technique as you’ll read, but I like it as a clear example of how it works)

Re: We stopped roadmap work for a week and fixed bugs

#212

Post by dijksterhuis »

NegativeK wrote: post #48
Celeo wrote: post #19

Earlier quoted context omitted.

Depending on the size of the team/org/company, working on anything other than the next feature is a hard sell to PM/PO/PgM/management.

I've had to inform leadership that stability is a feature, just like anything else, and that you can't just expect it to happen without giving it time. One leader kind of listened. Sort of. I'm pretty sure I was lucky.

i got lucky at my last shop. b2b place for like 2x other customer companies. eng manager person (who was also like 3x other managers :/ ) let everything get super broken and unstable.

when i took lead of eng it was quite an easy path to making it clear stability was critical. slow everything down and actually do QA. customer became super happy because basically 3x releases went out with minimal bugs/tweaks required. “users don’t want broken changes immediately, they want working changes every so often” was my spiel etc etc.

unfortunately it was impossible to convince people about that until they screwed it all up. i still struggle to let things “get bad so they can get good”, but am aware of the lesson today at least.

tl;dr sometimes you gotta let people break things so badly that they become open to another way

Re: We stopped roadmap work for a week and fixed bugs

#213

Post by QuiEgo »

QuiEgo wrote: post #207
ChrisMarshallNY wrote: post #16

I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…

As someone who works with hardware, hard to repo bugs can take months to track down. Your code, the compiler, or the hardware itself (which is often a complex ball of IP from dozens of manufacturers held together with a NoC) could all be a problem. The extra fun bugs are when a bug is due to problems in two or three of them combining together in the perfect storm to make a mega bug that is impossible to reproduce in…

Random example: I once worked on a debug where you were not allowed to send zero length packets due to a known HW bug. Okay fine, work around in SW. Turns out there was an HW eviction timer that was disabled. It was connected to a counter that counted sys clk ticks. Turns out it was not disabled entirely properly due to SW bug, so once every 2^32 ticks, it would trigger an evection, and if the queue happened to be empty, it would send a ZLP, which triggered the first bug (hard hang the system in a way that breaks the debugger). There were dozens of ways that could hard hang the system, this was just one. Good luck debugging that in two days.

Re: We stopped roadmap work for a week and fixed bugs

#214

Post by 2arrs2ells »

IgorPartola wrote: post #204
gregoriol wrote: post #175

Earlier quoted context omitted.

It must be part of the normal process. If the normal process leaves things like this to "some other time", one should start by fixing the process.

Say you are working on a banking system. You ship a login form, it is deployed, used by tons of people. Six months later you are mid-sprint on the final leg of a project that will hook your bank into the new FedNow system. There are dozens of departments working together to coordinate deploying this new setup as large amounts of money will be moved through it. You are elbows deep in the context of your part of this a…

This is a great example... except I think the right answer to "what exactly would you do in this case?" doesn't support your argument.

I'd document that mobile Opera with Javascript disabled is an unsupported config, and ask a team to make a help center doc asking mobile Opera users to enable JS.

Re: We stopped roadmap work for a week and fixed bugs

#215

Post by lalitmaganti »

eviks wrote: post #105

> closed a feature request from 2021! > It’s a classic fixit issue: a small improvement that never bubbled to the priority list. It took me one day to implement. One day for something that sat there for four years > The benefits of fixits > For the product: craftsmanship and care sorry, but this is not care when the priority system is so broken that it requires a full suspension, but only once a quarter > A hallmark…

> this is not care when the priority system is so broken that it requires a full suspension

I'm not sure I understand this line. The whole point of the fixit is to address the bugs which are considered "low priority" because they only appear in a edge case or are not quite 100% perfectly polished but still matter over the long tail of people using the product.

Or do you propose that every issue like this needs to be fixed before doing anything else?

Re: We stopped roadmap work for a week and fixed bugs

#216

Post by pixl97 »

lapcat wrote: post #29
superxpro12 wrote: post #9

Earlier quoted context omitted.

until we develop a way for MBA's with spreadsheets to quantify profit/loss w.r.t. bugs, it will never be valued.

The solution is to never hire an MBA.

'Why are we getting bought out by a company that cut corners and hired MBAs, and then fired?'

Re: We stopped roadmap work for a week and fixed bugs

#217

Post by zeroCalories »

pjmlp wrote: post #180
zeroCalories wrote: post #147

Earlier quoted context omitted.

This type of testing is incredibly expensive and you'll have a startup run circles around you, assuming a startup could even exist when the YC investment needs to stretch 4x as far for the same product. The real solution is to have individual software developers be licensed and personally liable for the damage their work does. Write horrible bugs? A licencing board will review your work. Make a calculated risk that d…

The kind of relates to proper Engineering titles, unfortunely many countries don't have a legal system in place for those that decide to call themselves engineers without going through the exam, and related Order of the Engineer.

I don't think titles are for anything besides establishing blame. If a company hires someone in a local where the engineer can't be held responsible, the executives and major investors should be held liable. That way things will naturally sort themselves out. Need something unimportant done? Offshore. Have some critical system? Hire someone that can take responsibility.

Re: We stopped roadmap work for a week and fixed bugs

#218

Post by criddell »

ChrisMarshallNY wrote: post #70
wahnfrieden wrote: post #38

Earlier quoted context omitted.

LLMs have helped me here the most. Adding copious detailed logging across the app on demand, then inspecting the logs to figure out the bug and even how to reproduce it.

Yes. I often just copy the whole core dump, and feed it into the prompt.

This is something that I've been trying to improve at. I work on a Windows application and so I get crash dumps that I open with WinDbg and then I usually start looking for exceptions.

Is this something an LLM could help with? What exactly do you mean when you say you feed a dump to the prompt?

Re: We stopped roadmap work for a week and fixed bugs

#219

Post by pjmlp »

zeroCalories wrote: post #217
pjmlp wrote: post #180

Earlier quoted context omitted.

The kind of relates to proper Engineering titles, unfortunely many countries don't have a legal system in place for those that decide to call themselves engineers without going through the exam, and related Order of the Engineer.

I don't think titles are for anything besides establishing blame. If a company hires someone in a local where the engineer can't be held responsible, the executives and major investors should be held liable. That way things will naturally sort themselves out. Need something unimportant done? Offshore. Have some critical system? Hire someone that can take responsibility.

As we say back home, responsability should never die alone.

Re: We stopped roadmap work for a week and fixed bugs

#220

Post by AbstractH24 »

ChrisMarshallNY wrote: post #16

I love the idea, but this line: > 1) no bug should take over 2 days Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done. That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. Also, I tend to attack bugs by priority/severity, as opposed to difficulty. Some of the most serious bugs are often qui…

> Is odd. It’s virtually impossible for me to estimate how long it will take to fix a bug, until the job is done.

Learning how to better estimate how long tasks take is one of my biggest goals. And one I've yet to even figure out how to master

Post reply on HN