My guess is they implemented dark mode, then discovered some legacy posts have videos with transparent backgrounds. As a quick fix, they decided to disable dark mode anytime someone scrolls down to a video.
Seems like one of those compromises to solve an 11th-hour bug.
In my case, I ended up accruing $100/day w/ Claude Code (on github workflows) so Max x20 was an easy decision.
Pro seems targeted at a very different use case. Personally, I’ve never used the chat enough to break even. But someone who uses it several times per day might.
ETA: I get that the benefits transfer between the two, just with different limits. I still think it’s pretty clear which kind of usage each plan is intended for.
> I don't think any good engineer ever claimed the title
I don’t claim to be a good engineer but I have made the claim in the title many times. Though it’s usually in the form of a more nuanced statement.
It’s about time, rather than money. If you can change a line of code to fix a bug before making your commit, that’s a lot faster than all the rigmarole of shipping the same fix later (new PR, code review, wait for CI, merge, deploy, etc.). Not to mention troubleshooting and debugging effort.
The multiplier depends on your context but the bar isn’t high. 100x a 30-second fix is about an hour of effort. I’ve worked in several teams where the average effort to change a line on prod approached that (with honest measurement, including context switching costs)
I believe in a soft form of that too (i.e. no specific numbers); the severity really depends on the type of project.
In few industrial and enterprise projects I worked on, once you cross past "testing", fixing a bug involved coordinating with another team, which was doing a test deployment or evaluation at customer site; at that point, extra process would kick in, and if it was severe enough (or you were unlucky enough) the customer side got wind of it, you could expect some extra e-mail rounds and possibly a meeting.
Now, if your bug didn't get noticed then, and failed in actual production... the time and cost multiplier was effectively unbounded. A fix for a simple and low-impact bug could take a week to get from commit to being ready to release, and then wait a month in limbo, because there are schedules to these kinds of projects (can't really do continuous delivery if each release triggers a validation and sign-off process on customer's end, that engages a team of people for a day or more). A fix for a more complex or impactful bug could become... the last thing you release, if the customer gives up on your product over it. Etc.
People like to focus on technical aspects (restoring databases, hard-to-reach hardware, etc.) when discussing this concept, but there are whole classes of projects where the driving aspect is bureaucracy - coordinating business side, altering long-term project plans, getting sign-off on testing, re-evaluating regulatory compliance, etc. That can quickly get arbitrarily expensive.
> It's probably still true, though, says formal methods expert
Seems like click bait. The thesis is predicated on the idea that people claim this is the result of some study. I’ve never once heard it presented that way. It’s a rule of thumb.
> The thesis is predicated on the idea that people claim this is the result of some study. I’ve never once heard it presented that way. It's a rule of thumb.
Code Complete cites eight sources to support the claim that the average cost to fix a defect introduced during requirements is 10-100x if it's not detected until after release. My qualm with Hillel's original assertion is that "They all use this chart from the 'IBM Systems Sciences Institute'" (emphasis added). I haven't personally vetted Steve McConnell's citations, but I am skeptical that they all share this common origin.
Laurent Bossavit’s The Leorechauns of Software Engineering looks into this claim (and several others) and finds that, yes, many of these studies do share a common origin, and often misquote/misrepresent it.
I'm quite sure that, over the years, I've seen this claim presented many times with a citation or at least reference pointing at a study somewhere; can't find any particular example right now, unfortunately.
(This claim sits in my memory adjacent to things like "fixed number of bugs per 1000 lines of code", in a bucket labeled "seen multiple times, supposedly came out of some study on software engineering, something IBM or ACM or such".)
If you have impressively low error rates in mind, I think they are coming from "They Write the Right Stuff":
> Consider these stats: the last three versions of the program - each
> 420,000 lines long-had just one error each. The last 11 versions of this
> software had a total of 17 errors. Commercial programs of equivalent
> complexity would have 5,000 errors.
I don't recall that. What I had in mind was this result being used in support of higher-level programming languages; the argument as I remember went, when comparing teams writing the same stuff in multiple languages (IIRC Java, and either Assembly or C, were involved), it was found that the number of bugs per KLOC was about the same in each case, but obviously the number of features implemented in the same number of lines was much greater in high-level, more expressive languages, therefore it's better to use high-level languages.
I do buy the general idea (more expressive language -> some class of bugs inexpressible by design + less lines of code for bugs to hide in), but I'm suspicious about the specific result showing a constant bug/KLOC ratio in all tested languages; feels more like a lucky statistical artifact than some deep, fundamental relationship.
The article you link to specifically calls out that they can't and won't speculate about whether age is a factor in causing car crashes. Elderly people have higher mortality rates in virtually all cases of injury and illness so it shouldn't be surprising this is true when they are involved in a car crash.
My guess is they implemented dark mode, then discovered some legacy posts have videos with transparent backgrounds. As a quick fix, they decided to disable dark mode anytime someone scrolls down to a video.
Seems like one of those compromises to solve an 11th-hour bug.
reply