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

331–340 of 356 posts

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

#331

Post by paulf38 »

snovv_crash wrote: post #101
com2kid wrote: post #89

Earlier quoted context omitted.

Have you ever fixed random memory corruption in an OS without memory protection? Best case you trap on memory access to an address if your debugger supports it (ours didn't). Worst case you go through every pointer that is known to access nearby memory and go over the code very very carefully. Of course it doesn't have to be a nearby pointer, it can be any pointer anywhere in the code base causing the problem, you ju…

This is why a test suite and mock application running on the host is so important. Tools like valgrind can be user to validate that you won't have any memory errors once you deploy to the platform that doesn't have protections against invalid accesses. It wouldn't have caught your issue in this case. But it would have eliminated a huge part of the search space your embedded engineers had to explore while hunting down…

Valgrind (and the sanitizers) are only as good as your test coverage.

Static analysis can cover all your code, though generally with a significant rate of false positives that you will need to analyse.

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

#332

Post by bagacrap »

ChrisMarshallNY wrote: post #136
ZaoLahma wrote: post #134

Earlier quoted context omitted.

> That said, unless fixing a bug requires a significant refactor/rewrite, I can’t imagine spending more than a day on one. The longer I work as a software engineer, the rarer it is that I get to work with bugs that take only a day to fix.

I've found the opposite to be true, in my case.

You must work on very simple codebases

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

#333

Post by OhMeadhbh »

Windchaser wrote: post #235
ChrisMarshallNY wrote: post #73

Earlier quoted context omitted.

I’m old enough to have used ICEs to trace program execution. They were damn cool. I seriously doubt that something like that, exists outside of a TSMC or Intel lab, these days.

/imagining using an internal combustion engine here

"Rejecting this pull request because the patch you submitted does not provide enough torque."

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

#334

Post by wavemode »

x0x0 wrote: post #249
RHSeeger wrote: post #57

Earlier quoted context omitted.

Bugs have priorities associated with them, too. It's reasonable for a new feature to be more important than fixing a lower priority bug. For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it.

I don't think, except for a direct regression, it's even possible to define a bug in a way that isn't the same as a feature request. They're identical: someone wants the software to do X, it doesn't do X, maybe we should make it do X. (Except, again, for it used to do X but now doesn't and that wasn't intentional.) Treating bugs as different than features and automatically pushing them to the front of the line likely…

A bug report does not mean that someone "wants" the software to do X, but rather that they -expect- the software to do X. If that expectation is correct, it's a bug, and if it's not correct then it's a feature request.

Most software is not formally specified, so it's not technically guaranteed that we can prove whether that expectation is correct or not. But, there is usually a collective understanding, reinforced by the software's own interface (e.g. "the button says Do X but I click it and X doesn't happen"), the documentation, and/or general technological norms (e.g. "it crashed" or "when I type text sometimes it disappears and I have to start over").

There are occasional ambiguous cases, but in practice these are uncommon in a well-run organization, and generally the job of a product manager is to have the final say on such matters via consultation with relevant stakeholders, contracts, etc.

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

#335

Post by IgorPartola »

BurningFrog wrote: post #322
IgorPartola wrote: post #309

Earlier quoted context omitted.

No. My argument is valid if you have deadlines and your resources are not infinite. Either you were the only one reporting bugs at which point of course you could fix the as you found them because they were always in your work context or you had no deadlines and could afford to switch context without the inefficiency of it affecting anything. In most situations you have users who also find bugs and report them when t…

Well, we clearly come from very different work methodologies. You have deadlines, velocity is a goal rather than a measurement, and probably several other (IMHO) process mistakes. In such systems, doing what is best for the organization can often be bad for your personal career. Still, that's probably the norm in much of the industry. My view is that having bugs is costly. They cause problems in development, and alie…

I suspect we do. Though you misunderstood my comment about velocity. I was using that purely as a way to demonstrate that something measurable is affected by dropping everything to fix a bug. Sounds like you do wait for an opportune moment to fix a bug and do not make it a top priority after all so I think you see the cost of interruptions.

But yes I am aware of lots of parts of this industry where you do not need to rush a project no matter what. I worked at places that had a breakneck velocity and at places where it is much more chill. I prefer the latter but I can say that I still want to ship software which means goals and deadlines. Bugs should be fixed ASAP but priorities must also be respected.

After 20 years doing this as a career, I agree this industry is a bit of a mess :)

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

#336

Post by danielbarla »

lalitmaganti wrote: post #325
danielbarla wrote: post #190

Earlier quoted context omitted.

Very interesting post, thank you! I'd also be curious to know the following: how many new errors or regressions were caused by the bug fixes?

Since the fixit just finished on Friday, I don't have hard numbers from this one I'm afraid :) Historically though, I would guess maybe 5-10% end up needing some followup fix which is itself usually smaller than the original (maybe a typo in some documentation or some edge case we spot when it hits prod etc). The smaller the original fixes, the less likely you are to need followups so another reason to prefer working…

I think 5-10% is pretty good, it probably means that the codebase is mostly understandable and maintainable. I have definitely worked on some which were full of little traps and landmines just waiting for eager do-gooders to step on, which was sadly a self-fulfilling prophecy for the app.

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

#337

Post by zelphirkalt »

DanielHB wrote: post #278
zelphirkalt wrote: post #127

Earlier quoted context omitted.

Frontend bugs mostly stem from usage of overblown frontend frameworks, that try to abstract from the basics of the web too much. When relying on browser defaults and web standards, proper semantic HTML and sane CSS usage, the scope of things that can go wrong is limited.

In my experience frontend bugs are usually from over-complicated business logic with layout-issues a distant second.

That requires business logic to run in the frontend in the first place though. One could argue it shouldn't. Anything that is checked in the frontend, needs to be re-checked in the backend anyway, because you cannot trust the frontend, because it is under control of the browser/user.

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

#338

Post by ChrisMarshallNY »

bagacrap wrote: post #332
ChrisMarshallNY wrote: post #136

Earlier quoted context omitted.

I've found the opposite to be true, in my case.

You must work on very simple codebases

Yes and no.

I tend to work alone, so my scope is limited.

Some of the stuff I work on is quite involved, anyway.

I’ve been at this game awhile (coding for over 40 years), so I have learned a few tricks.

Of course, I “cheat.” I’ve learned to write software that doesn’t tend to have that many bugs, and I also don’t have to deal with other people’s code, so much. I write code for myself, which means that I don’t get to practice my debugging, so much, these days.

You can see for yourself. Much of my work is open-source, or source-available: https://github.com/ChrisMarshallNY

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

#339

Post by tremon »

Retric wrote: post #265
HelloNurse wrote: post #244

Earlier quoted context omitted.

If there is a risk of a 10+ million dollar issue there is also some manager whose job is to overreact when they hear the announcement that someone wants to eliminate thing X, because they know that thing X is a useful part of the systems they are responsible for. In a reasonable organization only very minor systems can be undocumented enough to fall through the cracks.

In an ideal world sure, but knowledge gets lost every time someone randomly quits, dies, retires etc. Stuff that’s been working fine for years is easy for a team to forget about, especially when it’s a hidden dependency in some script that’s going to make some process quietly fail.

The OP explicitly said "if you involve all required management", and that is key here. Having a process that is responsible for X million dollar of revenue yet is owned by no manager is a liability for the business (as is having an asset in operation that serves no purpose). Identifying that situation in a controlled manner is much better than letting it linger until it surfaces at a moment of Murphy's choosing.

> Stuff that’s been working fine for years is easy for a team to forget about

That's why serious companies have a documentation system describing their processes, tools and dependencies.

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

#340

Post by tremon »

mschuster91 wrote: post #186
fragmede wrote: post #142

Earlier quoted context omitted.

that's a management/cultural problem. if no one knows why it's there, the right answer is to remove it and see what breaks. If you're too afraid to do anything, for nebulous cultural reasons, you're paralyzed by fear and no one's operating with any efficiency. It hits different when it's the senior expert that everyone revere's that invented everything the company depends on that does it, vs a summer intern vs Elon M…

> It hits different when it's the senior expert that everyone revere's that invented everything the company depends on that does it, vs a summer intern vs Elon Musk bought your company (Twitter). Hate the man for doing it messily and ungraciously, but you can't argue with the fact that it gets results. You can only say with a straight face that if you're not the one responsible to clean up after Musk or whatever CTO…

C-levels love the "shut it down and wait until someone cries up" method because it gives easy results on some arbitrary KPI metric without exposing them to the actual fallout

It's not in the C-level's job description to manage the daily operations of the company, they have business managers to do that. If there's an expensive asset in the company that's not (actively) owned by any business manager, that's a liability -- and it is in the C-level's job description to manage liabilities.

said C-level exec will defend themselves with "we gave X months of advance warning AND 10 months after the fact no one had complained"

And that's a perfectly valid defense, they're acting true to their role. The failure lies with the business/operations manager not being in control of their process tooling.

Post reply on HN