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

A single line of code cost $8000

pietrasiak.com

Post reply on HN
Print view View original

321–330 of 423 posts

Re: A single line of code cost $8000

#321

Post by aziaziazi »

vrosas wrote: post #305
ses1984 wrote: post #215

Earlier quoted context omitted.

The client might have a feature to retry certain failures, and it’s using a particular rate, probably not retrying n times one right after the other in rapid succession. This is called backoff. The server can return an override backoff so the server can tell the client how often or how quickly to retry. It’s nice to have in case some bug causes increased load somewhere, you can flip a value on the server and relieve…

Exactly. Without going too deep into the architecture, the clients are sending data to the backend in real time, but often that data is not actionable during certain periods, so the backend can tell the clients to bundle the data and try again after a certain amount of time, or just discard the data it's currently holding and try again later (i.e. in 5/10/n seconds)

Thanks for your responses. I’m used to "throttle", seems to be a synonym right?

Re: A single line of code cost $8000

#322

Post by outsidein »

skirge wrote: post #266
outsidein wrote: post #229

Earlier quoted context omitted.

Microsoft InTune WUDO has a similar bug costing my department 40000 € internal charging per month for firewall log traffic of blocked tcp 7680 requests. 86000 requests per day per client, 160 million per day total. MS confirmed the bug but did nothing to fix it.

how? Do you investigate each blocked packet as separate alert?

Yes, all packets get logged (metadata only). Otherwise we wouldn’t know there is an issue.

Those packets consume bandwidth and device utilization, too but this is flat fee, whereas log traffic is measured per GB so we investigated where an unexpected growth came from.

Re: A single line of code cost $8000

#323

Post by yojo »

pcthrowaway wrote: post #299
yojo wrote: post #119

Earlier quoted context omitted.

That’s pretty much the floor for an Electron app. If you’re a small shop or solo dev, it is real hard to justify going native on three platforms when electron gives it for (near) free. And outside of HN, no one seems to blink at a 250MB bundle. There are alternatives like Tauri that use the system browser and allow substantially smaller bundles, but they’re not nearly as mature as Electron, and you will get cross pla…

> And outside of HN, no one seems to blink at a 250MB bundle. Please, many people connect to the internet via a mobile phone hotspot, at least occasionally. This bug would likely cause you to go through your entire monthly data in a few hours or less.

I’m not excusing this bug. There are several poor decisions that went into this issue, but my contention is that using electron (with the resulting 250mb bundle) is not one of them.

You should probably not roll your own auto-updater.

If you do, checking every 5 minutes for updates is waaaay too often (and likely hurts battery life by triggering the radio).

And triggering a download without a user-prompt also feels hostile to me.

The app size compounds the problem here, but the core issue is bad choices around auto-updating

Re: A single line of code cost $8000

#324

Post by chinchilla2020 »

"A single line of code caused "

Yes, a single line of code is in the stack trace every time a bug happens. Why does every headline have to push this clickbait?

All errors occur at a single line in the program - and every single line is interconnected to the rest of the program, so it's an irrelevant statement.

Re: A single line of code cost $8000

#325

Post by cbsks »

monkeyelite wrote: post #228
Capricorn2481 wrote: post #186

Earlier quoted context omitted.

> Code reviews kill velocity - introduce context switching, and are make work This is the same point three times, and I don't agree with it. This is like saying tests kill velocity, there's nothing high velocity about introducing bugs to your code base. Everything introduces context switching, there's nothing special about code reviews that makes it worse than answering emails, but I'm not going to ignore an importan…

> This is the same point three times No it isn’t. Fake work, synchronization, and context switching are all separate problems. > code reviews are a way to catch those I said you can do reviews - but there is no reason to stop work to do them. Why not require two or three reviews if they are so helpful at finding mistakes? I agree everyone makes mistakes - that’s why I would design a process around fixing mistakes, no…

> Why not require two or three reviews if they are so helpful at finding mistakes?

For secure software, e.g. ASIL-D, you will absolutely have a minimum 2 reviewers. And that’s just for the development branch. Merging to a release branch requires additional sign offs from the release manager, safety manager, and QA.

By design the process slows down “velocity”, but it definitely increases code quality and reduces bugs.

Re: A single line of code cost $8000

#326

Post by monkeyelite »

mugsie wrote: post #280
monkeyelite wrote: post #148

Earlier quoted context omitted.

Code reviews kill velocity - introduce context switching, and are make work, it feels like you’re doing something to make a PR etc but your not. The context it makes the most sense is accepting code from strangers in a low trust environment. The alternative to trying to prevent mistakes is making it easy to find and correct them. Run CI on code after it’s been merged and send out emails if it’s failed. At the end of…

> Code reviews kill velocity Yes, they kill your velocity. However, the velocity of a team can be massively increased by shipping small things a lot more often. Stable branches that sit around for weeks are the real velocity killer, and make things a lot more risky on deployment.

I agree with all of that - no contradiction.

Re: A single line of code cost $8000

#327

Post by monkeyelite »

ljm wrote: post #302
monkeyelite wrote: post #148

Earlier quoted context omitted.

Code reviews kill velocity - introduce context switching, and are make work, it feels like you’re doing something to make a PR etc but your not. The context it makes the most sense is accepting code from strangers in a low trust environment. The alternative to trying to prevent mistakes is making it easy to find and correct them. Run CI on code after it’s been merged and send out emails if it’s failed. At the end of…

The up-front cost of code review can be easily be tripled or quadrupled when it’s distributed over several weeks after the fact in the form of unplanned work, each instance of which incurs its own cost of context switching, as well as the cost of potential rework. The purpose of such a review is a deliberate bottleneck in the earlier stage of development to stop it becoming a much larger bottleneck further down the l…

> The up-front cost of code review can be easily be tripled or quadrupled when it’s distributed over several weeks

You’re taking a more extreme position than the one I’m stating. You can review every day or every hour if you want.

> a deliberate bottleneck in the earlier stage

Wouldn’t it be better if we could catch bugs AND avoid the bottleneck? That’s the vision. Good intentions may disagree about how to accomplish that.

Re: A single line of code cost $8000

#328

Post by monkeyelite »

mugsie wrote: post #277
monkeyelite wrote: post #228

Earlier quoted context omitted.

> This is the same point three times No it isn’t. Fake work, synchronization, and context switching are all separate problems. > code reviews are a way to catch those I said you can do reviews - but there is no reason to stop work to do them. Why not require two or three reviews if they are so helpful at finding mistakes? I agree everyone makes mistakes - that’s why I would design a process around fixing mistakes, no…

> Why not require two or three reviews if they are so helpful at finding mistakes? Places do? a lot of opensource projects have the concept of dual reviews, and a lot of code bases have CODEOWNERS to ensure the people with the context review the code, so you could have 5-10 reviewers if you do a large PR

Does it make the code better? The best projects are the ones with the most review l?

Re: A single line of code cost $8000

#329

Post by monkeyelite »

Capricorn2481 wrote: post #279
monkeyelite wrote: post #228

Earlier quoted context omitted.

> This is the same point three times No it isn’t. Fake work, synchronization, and context switching are all separate problems. > code reviews are a way to catch those I said you can do reviews - but there is no reason to stop work to do them. Why not require two or three reviews if they are so helpful at finding mistakes? I agree everyone makes mistakes - that’s why I would design a process around fixing mistakes, no…

> No it isn’t. Fake work, synchronization, and context switching are all separate problems Context switching is a problem because it...kills velocity. Fake work is a problem because it kills velocity. You're saying it's time that could be better spent elsewhere, but trying to make it sound wider. I disagree with the premise. Synchronization is a new word, unrelated to what you originally wrote. > How many times have…

> Synchronization is a new word, unrelated to what you originally wrote.

I believe you can figure it out.

> Never?

Ok well I’m trying to talk to people who have that problem. Because I and my team do.

Re: A single line of code cost $8000

#330

Post by monkeyelite »

cbsks wrote: post #325
monkeyelite wrote: post #228

Earlier quoted context omitted.

> This is the same point three times No it isn’t. Fake work, synchronization, and context switching are all separate problems. > code reviews are a way to catch those I said you can do reviews - but there is no reason to stop work to do them. Why not require two or three reviews if they are so helpful at finding mistakes? I agree everyone makes mistakes - that’s why I would design a process around fixing mistakes, no…

> Why not require two or three reviews if they are so helpful at finding mistakes? For secure software, e.g. ASIL-D, you will absolutely have a minimum 2 reviewers. And that’s just for the development branch. Merging to a release branch requires additional sign offs from the release manager, safety manager, and QA. By design the process slows down “velocity”, but it definitely increases code quality and reduces bugs.

Once again let me reframe the mindset. Trying to get a perfect change where you anticipate every possible thing that will go wrong beforehand is impossible - or at least extremely costly. The alternative is to spend your effort on making it easy to find and fix problems after.
Post reply on HN