This is my headcanon when I see a simple but long lasting bug like this at a large company.
To you or I, it seems simple. Clearly things are not working as intended and the fix is trivial. Raise a bug in the tracking system if you really have to, then just fix it, right?
Here’s the thing. That code was written completely according to the specification. The path there was clearly there in the requirements. So what? So…that means it’s not a bug, it’s a feature change. And if it’s not a bug, that means we can’t officially use our allocated (but always shrinking) bugfix time to work on it.
If we want to fix it, we need to put in a feature change request. That means we have to articulate the value to the business in changing this feature and explain why we think the original specification is wrong. We can’t get confirmation from the spec author because they are no longer with the company. That means we have to prove that it was written incorrectly.
If…and that’s a big if, we can articulate that there’s business value in doing this and that the original specification was likely incorrect, then we get to the really fun part. Prioritisation.
You see, the team that built that feature doesn’t exist anymore. Once the bulk of the features were done, they got disbanded and the engineers moved to other teams. Technically there should be a single team responsible for every feature so it gets maintained, but in practice it doesn’t really work that way. The people on the official team that’s responsible haven’t touched any of that code. They’re not too keen on starting either because they have their own priorities.
So after all that, the task sits in the backlog of that team, neglected. Eventually in some distanct sprint planning session it will be flagged as an old ticket. You, who raised it, would have left the company and nobody in the meeting has context about why the task was created. Isn’t that miscategorised, shouldn’t it be a bug? Why is it with our team, is it even worth doing? Then it will be pruned from the backlog. The sad task that was fought for so valiantly, only to die sadly in the cutting room floor of a backlog grooming session.
Then one day, the bug will annoy a newcomer so much, they’ll just sneak the change in under another ticket and the bug will finally be fixed. Months before the product gets scrapped for a worse replacement. What are the specifications of the replacement software based on? That’s right, the original specs of the old system to ensure backwards compatibility.
Must be nice to work work in such an agile company. Around here, we need to produce an updated requirements specification. Review that specification internally. Send the updated specification out to stakeholders for review. Put a bug in the backlog. Wait until someone important files a new bug report (which is now an actual bug report). Actually produce a fix. Hold a change review meeting. Merge the fix. Test the fix. Fail during testing because the tester is new to the project and flags 100 critical bugs that have been sitting in the backlog for years. Ship a release. Receive a bug report that we no longer produce screenshots. Fly an engineer to location to investigate. Advice the customer to update a 5 line script to point to the new location. “We don’t have bandwidth to update that system.”. Hide the fix behind an obscure undocumented option that defaults to off. Ship an emergency bug fix. Wait for the next bug report. Close bug report as "user error. User forgot to set enable ‘screenshots are not videos’ flag in tweaks>advanced>video menu ".
Right… We had to get up in the morning at ten o’clock at night, half an hour before we went to bed, eat a lump of cold poison, work twenty-nine hours a day down the mill, and pay the mill owner for permission to come to work, and when we got home… our dad would kill us and dance about on our graves singing “Hallelujah.”
That may be true in some truly well organized (usually “legacy big corpo” companies).
Where I’ve worked it’s more like:
- Requirements only cover user-facing features, if that. (Not so) senior engineers are left to bridge the gap between UI mockups and literally everything else.
- Implementation issue is accidentally introduced
- Priority on the bug is lower than new features so no-one has any way to justify working on it
- One day a dev might be personally annoyed enough by the issue that they fix the part as part of some tangentially related work. Else it stays like that forever.
That is a basic side-effect of Agile development. If you have implementation details figured out to such an extent before writing the code, you are not doing agile, you are doing waterfall. Which has a time and a place, but that time and place is typically banking or medical or wherever you’re okay with spending several times the time and money to get maximum reliability (which is a different metric than quality!).
I bet NVIDIA has driver crashes to figure out, and I know which of those issues I’d want them to focus on first if I used their windows driver.
Agile in corpo is usually the soul-crushing, not working kind, where the participants don’t get the decision power they need for it to be working and not soul-crushing.
I’ve been a PM for about 7 years and God do I miss waterfall. My team is lucky to get a week or two of testing now and that usually puts us right at code freeze so any issues we find we now have to justify to multiple teams and dev on why it needs to be fixed.
How much of it is due to Agile (which is a very broad concept even though some people mistakenly equate it with scrum), and how much is it due to corporate pressures and inadequate processes though?
I find Agile conceptually meshes a lot better with “standard” product and solutions development thanks to the tighter feedback loops and increased reliance on local expertise over centralized planning. This only gets truer as project complexity grows.
However some companies try to make Agile work with top-down decision making and/or hard deadlines, which are deadly antipatterns. As for lack of time/resources and/or timesheet micro-management, this isn’t a problem unique to Agile nor something that waterfall is exempt from.
Good agile teams are mostly independent and can define their own testing/release cycle as required for a given project; though of course when that happens there are at least a couple layers of management who feel a burning itch to stuff their dirty nosed where they don’t belong because if the team succeeds despite their lack of direct involvement then everyone might realize the emperor has no pants.
I mean if you think about it, screen shots are just single frame videos 🤷🏻♂️
Any Linux users here? ~/Pictures/Screenshots
%AppData%\Roaming\654163413219648163\User\default\data\imagedata\images\NVIDIA Corp.\Desktop
Just patch it so it saves where you like it. Oh you don’t have the source? Sucks to be you.
