Into The Unknown

I'm as big a big fan of HD content as the next geek, and I've found (as have many others) that on my PCs, along with AC3Filter and the Haali Media Splitter running the show for my decoding, CoreAVC is the most effective and efficient video codec for H.264/AVC content. However, in the CoreCodec discussion forums there's been lots of discussion about delays and widespread reports of bugs in the new version (1.3.0.0), including lack of playback once it's installed, incompatibility with Vista, and the inability to roll back to 1.2 once 1.3 has been installed - even if it's uninstalled.

The CoreCodec site, which has an online portal system for those who have purchased the codec (including personalised download links for the installers) is also in a state of hiatus, with all purchasing facilities suspended until the new versions of their most popular software - Coreplayer Mobile (formerly TCPMP, which I still use on my Vario 2) and CoreAVC - are bugfixed and compiled.

The CoreCodec developers have also commented several times on their forums that once the bugs are sorted out, 1.3.0.1 will be made available for purchase and everything will return back to normal, but the delays are increasing and feedback from the developers is less than forthcoming.


It's a shame, because CoreAVC is a really cracking codec - its performance on less-than-brand new systems is noticeably superior when put up against its main competitors, and all the processing is done in software as well - and I hate to see this small bit of bad press affect it. I have every hope that CoreAVC 1.3.0.1 will be released soon, as the developers promise. When it does I will be suggesting to the developers that they keep a closer eye on their (if small, but very active and vocal) community residing on their forums and on other forums like Doom9 so as to revise their code and fix problems much sooner. They are usually pretty good when it comes to fixing problems for next release, and their community acknowledges this, but equally this whole issue could also well be ascribed to taking a product out of beta a little too soon.

Conversely, Google loves its 'beta' tag, and applies it to just about everything (I'm still a little amazed that Google Search still isn't labeled as beta, as they're continually adding new features) - it raises an interesting question, too: given the possibility for keeping a product in continuous beta status, and releasing updates thick and fast as problems occur, is that a better practice for developers than to work a long time on fixing every problem they can foresee, releasing it to the masses then firefighting when a bunch of users come along with a new, unforeseen problem? The latter is what appears to have affected CoreCodec's product, but the former situation (thinking of Google again) also has the side-effect of devaluing the 'beta' status, and, in effect, merging together the beta and RTM levels of development until both terms have little relevance to their original meanings.


Maybe it's time for developers to rethink their usage of beta as a terminology for defining "it works, but it's not properly finished yet... But what the hell everyone, just use it anyway and don't bitch if it breaks on you", because it also - to me anyway - devalues the usefulness of effective Quality Control testing by a controlled group of testers. Every good product (should) have QC and QA performed on it at every major developmental stage, and usability tests to boot, otherwise you end up with a product which has been designed engineers without a thought paid to how regular users are going to use it.

The software which runs on 90% of the UK's checkout EFTPOS terminals (tills to you and me) is a prime example of software developed by developers without it ever having even a once-over from a usability engineer. That's possibly the most important stage of a software's beta cycle, and it's being neglected in this increasing trend of Web 2.0 "unfinishedness".


In fact, I think the beta tag should be dropped from many of the programs that use it, and replaced with a term like "almost" - that'd encourage developers to get it finished and out the door in a properly working state much faster than they do currently. Tagging something 'beta' almost encourages slower development, which isn't always good - last time I did something like that, I ended up spending weeks and weeks on it and continually losing my train of thought, which slowed down development as a whole and meant that I also lost some good ideas which I'd had but not started to work on.

Beta's not always a good thing to call something. Maybe beta-with-next-stage-deadline would be more appropriate for the majority of live, in-development projects I see on the web these days...