I was thinking about that too, when I read the article. It seemed the libav guys are perfectionists, while the ffmpeg guys focus on getting things done.
It made me wonder in my own professional work: should I also focus more on getting things done instead of trying to find the best solution? Will that approach give better results in the end? It's hard to tell if libav is more maintainable in the end, especially if no one will use it in the next few years, which might be the result of Debian backing down on libav.
Still, the fact that ffmpeg has more features and its devs fix bugs and security issues more quickly seem to suggest that ffmpeg is more maintainable, even if the libav maintainer claims otherwise.
---
In the end it's better to work on a (perhaps) less maintainable product that people use compared to a very maintainable product that no one uses.
>>It made me wonder in my own professional work: should I also focus more on getting things done instead of trying to find the best solution?
As an SDET who has dealt with code perfectionist, please just focus on getting things done and features shipped. Assuming that bugs aren't life & death in your product like car software to deploy airbags, or huge consequences/delays like a land rover destine for Mars missing its mark and flying off into space. Worry about all that perfectionist stuff later, when you're sure it actually matters. Until then, as long as your code isn't a hideous abomination, it's fine. Just ship it. If you have passionate QA/SDETs, they'll find the critical bugs and do performance tests if needed. This is especially true if the product had a good spec that it was developed around.
That said, don't take any shortcuts when it comes to security!
The perfectionist in me thinks in another way: time is an important resource and time taken should be considered a penalty from the perfection point. That is, if you spend too much time implementing a feature "perfectly", that is not perfect in the 4D spacetime continuum.
> should I also focus more on getting things done instead of trying to find the best solution?
This question can only be answered in the context of the project's life cycle. Is it in the early stages? Are there many downstream users relying on its stability? How clearly is the distinction between internals and interface communicated to downstream users? How technical are the end users?
> the fact that ffmpeg has more features and its devs fix bugs and security issues more quickly seem to suggest that ffmpeg is more maintainable
Or it could just be that ffmpeg has people who are willing to dedicate a much larger amount of time to their maintainership duties. Often differences like this have much more to do with nontechnical causes like corporate support.
> It made me wonder in my own professional work: should I also focus more on getting things done instead of trying to find the best solution? Will that approach give better results in the end?
From personal experience: yes. The problem is the perfect solution is usually only obvious in hindsight, after you've done the work, so the quicker you get there the quicker you can get to where it "should" be.
libav has less features and is less secure. If they can't keep up with fixing security bugs, I can't help but wonder on how they fare on less important bugs, probably not that good either.
Given how there appear to be no problems adding new features to ffmpeg, any technical debt the project has incurred seems to be within manageable range.
It doesn't look at all, as if libav is better, by any reasonable metric.
The nuance in "worse is better" is that it's about the approach, not the output. libav's approach is to focus on an elegant API and software architecture instead of focusing on development speed and features.
The output in the short term is that libav is riddled with bugs, the hope is that in the long term this will pay off. Unfortunately in the interim ffmpeg seems to have propelled ahead.
If you re-design, refactor or rewrite your code to improve something but leave bugs behind in the process you are not improving anything, your just shoveling shit from one place to the other.
It made me wonder in my own professional work: should I also focus more on getting things done instead of trying to find the best solution? Will that approach give better results in the end? It's hard to tell if libav is more maintainable in the end, especially if no one will use it in the next few years, which might be the result of Debian backing down on libav.
Still, the fact that ffmpeg has more features and its devs fix bugs and security issues more quickly seem to suggest that ffmpeg is more maintainable, even if the libav maintainer claims otherwise.
---
In the end it's better to work on a (perhaps) less maintainable product that people use compared to a very maintainable product that no one uses.