In an ideal world -- or, rather, an ideal world from the programmer's standpoint -- software is written, polished, completed, shoved out the door, and that's that. In the real world, it doesn't work that way. Software programs are now too large and complex to be pushed out reasonably bug-free the first time, at least for the waiting time and cost that consumers are willing to put up with. Even in the world of commercial packaged software, where releasing updates is an expensive process given the need to actually find and pull people who still know the code and regression test the software, you're still generally expected to release one patch. But how do you know what to patch?
Crashes are finicky. If you tell people to simply report crashes to you, you're going to get a lot of worthless reports, guaranteed. This doesn't mean your users are stupid or unmotivated, because they largely aren't, but most aren't trained as to what they should look for and report in a software failure, much less for your software. So the best thing you can do to improve your crash diagnostic capabilities is to rig your software to report what you want to know, and that can be done by having it write out a crash report. A crash report is a quick dump of the state of the program and the program's environment at the time of the failure. Since it is done programmatically, a lot of reporting bias is removed, and even if the report itself isn't useful, you can match it to other reports to obtain clues as to what is causing failures in your application.
That leaves the problem of what to put in the crash report.
I'll assume that you don't have one of the easy methods available, such as trucking the person and his machine in next to you (not generally feasible unless you're dealing with in-house QA), and taking a full memory image of the entire process, which takes forever to upload and waste tremendous amounts of storage and bandwidth. What we're looking for here are items that (a) speed up identification of the most common failures, (b) are space efficient, and (c) fairly easy to implement. You don't need a truckload of information in your crash report for it to be effective in helping reduce defects in subsequent releases.(Read more....)
I have some good news to report with regard to the word mark issue in Germany. I have actually known about this for several days, but was unable to disclose it publicly until successful delivery of the legal notice.
In response to a request filed on my behalf, a regional court judge in Stuttgart, Germany has granted a preliminary injunction against Mr. Raimar Kliemen prohibiting him from (a) using the trademark VIRTUALDUB in conjunction with computer software, or (b) sending warning letters to third parties with regard to my software program VirtualDub or links to its associated web sites. He is also liable for costs involved in obtaining this injunction.
The issue is not completely resolved at this point; Mr. Kliemen can contest the decision, in which case I would be liable for costs should I lose (Germany has a sort of "loser pays" legal system). However, I believe this to be a remote possibility, given that the mark is currently in the process of being cancelled on initiative of the German Patent and Trademark Office itself.
I hope this will be of assurance to all VirtualDub users in Germany, and particularly those who have unfortunately been affected by Mr. Kliemen's actions.(Read more....)