Ask Hackaday: What About Imperfect Features? [Hackaday]

View Article on Hackaday

Throughout the last few years’ time, I’ve been seeing sparks of an eternal discussion here and there. It’s a nuanced one, but if I could summarize, it’s about different feature development strategies we can follow to design things, especially if they’re aimed at a larger market. Specifically – when adding a feature, how complete and perfect should it be?

A while back, I read a Mastodon thread about VLC not implementing backwards per-frame skipping. At the surface level, it’s about an indignant user asking – what’s the deal with VLC not having a “go back a frame” button? A ton of video players have this feature implemented. There’s a forum thread linked, and, reading it could leave you with a good few conflicting emotions. Here’s a recap.

In what appears to be one of multiple threads asking about a ‘previous frame’ button in VLC, there’s an 82-post discussion involving multiple different VLC developers. The users’ argument is that it appears to be clearly technically possible to add a ‘previous frame’ button in practice, and the developers’ argument is that it’s technologically complex to implement in some cases – for certain formats, even impossible to implement! Let’s go into the developers’ stated reasoning in more details, then – here’s what you can find in the thread, to the best of my ability.

The Mess Of Video Formats And Human Emotions

Video compression can get complex – you wouldn’t be surprised to hear that, in overwhelming majority of video formats, the compression algorithms generally store between-frame changes, with occasional full frames stored so that seek isn’t too expensive. That said, it can get even more complex than this, with some formats being particularly seek-unfriendly due to blurring the line of what even constitutes a separate frame. Again, we have real-world examples of, but this does create a non-unified interface for users. I could not find an argument made by VLC devs addressing the suggestion to enable previous frame seek for some formats and not others, with UI changes to match, but I did find a different take.

The gist is, VLC developers don’t see a clean way to implement seek, as-is. Whatever other video players are doing, it needs to be investigated, and then it might turn out to be messy code where the principles won’t even transfer into VLC without creating a maintenance burden. The devs have the best insight into the codebase, as it stands, and if they. Of course, there’s been users who haven’t taken it lightly, and together with overwhelmingly reasonable messages, the thread has seen a considerable backlash to what appears to be an obvious feature that should’ve been added years ago.

One of the developers’ core arguments is that the feature can’t work perfectly in all cases. The problem is that nobody was asking for perfection. If the developers’ responses are focused on how a feature can’t be implemented perfectly but the users in question aren’t asking for a perfect implementation, maybe the developers are approaching this feature from a fundamentally wrong angle.

This puts into question the claim of an implementation being complex – is it really as complex as you claim, or did you back yourself into a corner while striving for an impossible standard? Cases of developers backing themselves into a corner aren’t unheard of, and reading the thread, it’s really not clear that this is not the case. This results in developers strongly communicating a pretty common failure mode, while fervently denying it could be an option.

The communication disconnect isn’t helped by fundamentally conflicting messaging. Throughout the developers’ messages, if you are to treat them as seriously as possible, you can piece together these serious points: “we genuinely don’t know how to implement this to our standards, we don’t want to provide users with a bad user experience, but we are open to pull requests”. However, these points are surrounded by developers’ replies like “it’s not generally possible”, or “if it’s so easy, why aren’t you doing it”, or a variation of “this can’t be done perfectly [but it can be done for some cases]”.

Obviously, open-source developers aren’t gods expected to solve every feature request that ever appears, but that’s the thing, you’re supposed to be able to contribute to open-source, and it’s not really clear if anyone can contribute to solving this problem. There is two incompatible stances here – the first stance is “sorry, we don’t know, help us if you can”, and the second stance is “we expect perfection and know that to be impossible”. This incompatibility isn’t explicit, but it’s weaved throughout the thread when you read between the lines, and this makes it really tricky to determine if someone’s work would be appreciated in case someone were to go implement the feature and do a pull request.

Will your pull request get the positive bias as a solution to a problem that developers are struggling to solve for their users, as is a custom in open-source land, or will it get denigrated as a solution to a problem that can’t be solved perfectly anyway? I guess you just can’t know until you put in hours of work. When such an uncertainty is going to hover over you all throughout you figuring out a way to do a clean implementation, it’s going to be hard to forget that you could be doing literally anything more promising with your time instead. And, given negativity bias, will some people’s experience with VLC be tarnished by reading this forum thread as they’re looking for a solution to a problem that’s a keypress away in all other players?

Bridging The Gap

VLC users and VLC developers are talking past each other, while sending each other implicit messages with a fundamentally dismissive core. It’s an open-source community problem, but pull requests and forks are the wrong tools here. Besides, the technical problem is solved – one of the last posts in the forum thread tells us that there’s a plugin which solves this problem, adding a ‘previous frame’ button. It might require a finicky sequence of actions to operate or install, but it’s a solution better than switching to a different player, something that you’ll see quite a few people state in the thread in frustration.

When you put on the user gloves, what do you have to say to a developer trying to choose between an imperfectly implemented feature and not implementing it at all? Which one would you rather work with? And when you sit in a developer’s seat, how you do you feel about working away at an imperfect feature that might just turn into a maintenance burden, especially if you can’t get yourself comfortable with implementing it?