i will never forgive the emby team for creating the single most idiotic (although rather funny) transcoding system.
It has a resolution selection, along with a bitrate selection, so you would think it forces transcoding.
It turns out the resolution is actually just a suggestion, and the bitrate is what it targets, if it doesn’t meet the bitrate, it will transcode, and if you get lucky, it might transcode to the specified resolution.
As someone in the dev team for a “business app”, we probably know about most or all of them, but they’re just not important enough for anyone in management to prioritize them as part of a sprint. It’s also possible no one has given us reproducible steps to make them happen, so we just straight up don’t know what to fix. Usually the former though.
They usually do yes however it’s all about prioritization.
You may have hundreds or thousands or open requests and issues.
With tens of thousands of closed issues that were either not reproducible, not actually problems, or largely indecipherable.
There’s usually a feature roadmap which is where most of the development money and time is spent. If it’s an older business application then certain bugs might easily take weeks to find, fix, test, validate, go through user acceptance, A/B test, and then deploy. But fixing is expensive work, so if the bug isn’t severe it’s usually deprioritized next to higher priority work.
It seems like I’m constantly finding bugs in businesses’ apps. Do they not have people test them?
They do, and they have a backlog of hundreds of issues to fix and they must prioritise then. If fixing a bug doesn’t make money, it’s not priority.
I deal with this every day. It hurts me to my core.
I hate how they’ll spend 4 years squashing all the bugs…and then they cancel the software, and release a new buggy version.
i will never forgive the emby team for creating the single most idiotic (although rather funny) transcoding system.
It has a resolution selection, along with a bitrate selection, so you would think it forces transcoding.
It turns out the resolution is actually just a suggestion, and the bitrate is what it targets, if it doesn’t meet the bitrate, it will transcode, and if you get lucky, it might transcode to the specified resolution.
cough Sonos
sure they do, you’re one of them
As someone in the dev team for a “business app”, we probably know about most or all of them, but they’re just not important enough for anyone in management to prioritize them as part of a sprint. It’s also possible no one has given us reproducible steps to make them happen, so we just straight up don’t know what to fix. Usually the former though.
they test them…
Whether they do anything with that testing is another story,.
We are supposed to be testing them? /s
you already are smh, you just don’t know it!
I would fix that bug but the complete rewrite that management has had me working on for the past two years will make it obsolete anyway.
Ah, the circle of life
Sometimes no.
Yes, they’re called “customers”.
Sometimes. Other times they layoff the QAs and anyone else whose job is about quality.
They usually do yes however it’s all about prioritization.
You may have hundreds or thousands or open requests and issues.
With tens of thousands of closed issues that were either not reproducible, not actually problems, or largely indecipherable.
There’s usually a feature roadmap which is where most of the development money and time is spent. If it’s an older business application then certain bugs might easily take weeks to find, fix, test, validate, go through user acceptance, A/B test, and then deploy. But fixing is expensive work, so if the bug isn’t severe it’s usually deprioritized next to higher priority work.