No you have misunderstood me. I am saying common edge cases for new features that are being developed and are specifically part of a release (this release added support for larger cards) should be tested better. This is bad QA in their development cycleYou've hit on a common thought: that cameras should be bug-free from day one. In that light, the entire list of fixes in version 1.1.0 would indeed seem like an admission of total failure, especially since those bugs have been present for about a year.
This isn't about ideal or bug free software, but rather basic testing and the frequency of such recalls in recent time. As I said, if it happens once, maybe OK, when we are seeing it often, the SDLC is suspect
This one was not that complex. If I am being asked to add support for bigger cards, on an existing product, some of the basic regression test cases would revolve around interoperability between different sized cards before and after the change. Once these tests are coded, they are there for future. Complexity doesn't just grow in a day - just like the code gets added, so do the related tests and having a gamut of them available takes all the complexity away.However, I see it differently, less drastically. While it's true that ideally software would be perfect on release, the reality of developing complex firmware for modern cameras means it's nearly impossible to catch every single bug before widespread, real-world use. Think of the countless combinations of settings, accessories, and user scenarios.
That is how complex software is built in the first place, so that we don't find ourselves saying - oh it's so complex, we can't support it well enough. In fact, if the argument for complexity comes up in context of change inflicted bugs, it becomes a software design issue in addition to testing.
Again, I am not arguing about how they handled it, but that this one should have been avoided. Same feeling for some previous pulls.So, for me, this isn't an admission of "total failure," but rather a sign of continuous commitment and the product's ongoing maturity. These updates are how companies respond to real-world feedback, refine their products, and ensure long-term support. It's an evolutionary process, not a one-time, flawless launch.
Note that I am not being critical of the bugs they fixed to have existed in their previous version of firmware. In fact my first reaction to the release that I posted early on was a positive acknowledgement of long list of bug fixes included. The argument is not for flawless bug free software. The issue is trivial regressions that are avoidable through better TDD
Anyway, it seems we just have a different bar on what we consider avoidable and unavoidable bugs. I believe issues like the one that caused this pull are avoidable through better dev practices. If you think that's a bar too high, that's fine. I would still encourage canon to retrospect on their SDLC at this stage
And since this reminded me of my first reaction, is there an excuse for not proof reading their release notes too? Is that very complex as well? At some point it becomes questionable whether the issue is systematic
--
PicPocket
Last edited: