Unhappy about the VT Announcement.

[AbdulAlhazred]

Really.

How many examples of software releases in the world can you cite that are bug free? Do you believe for even a femtosecond that bugs in software are inevitable? Or do you understand that bugs are simply a cost effective drawback that companies don't iron out because they've created a market condition where consumers will tolerate them?

I have an extremely low tolerance for buggy software and poor website design and implementation. The only reason for it is laziness and incompetence. Companies have somehow duped the public into believing and accepting this status quo, when in fact the reality is that a bug-free application isn't impossible, it's just far more expensive to produce and becomes less cost effective to iron out the bugs than it is to simply lose 0.1% of sales because of people like me.

If people weren't so tolerant of buggy, crappy, amateur-hour efforts, then do you really think that companies would attempt to force such product down our throats? If people didn't buy this stuff, companies would make more of an effort and we'd live in a far less buggy world.

But we don't and so we get things like the Character Builder, Monster Builder, GleeMax and now this weak-sauce VTT. Vote with your wallet by not giving WotC money and you can bet they'll either quit producing low-quality digital content altogether, or they'll up their game and actually make the effort to produce something worth paying for.

Actually, being somewhat of an expert on this subject, I'm afraid I have to tell you that your notions of what is and isn't possible in the software world are not in line with the actual facts of the situation. There are various ways of defining the complexity of software. Regardless of which measures you use what you will find is that said complexity grows in a geometric fashion as any software incorporates more functionality. Beyond that even the 'simplest' seeming user applications incorporate vast amounts of code indirectly. For instance the Linux kernel includes several MILLION lines of source code. That makes it easily larger than the largest textual works ever written by man. Nobody fully understands these large bulks of code or all of the interactions that can happen. Many of these interactions are extremely rare and cannot feasibly be produced on demand by any testing framework.

The upshot is that bugs ALWAYS exist. No piece of software ever written is bug free. In fact there is no known way by analysis to demonstrate that software IS bug free nor to identify where these bugs are. Various practices and processes can improve the reliability of software. All of them are very labor intensive and costly. The general result is that you can reduce and eliminate bugs pretty easily when there are lots of them, but the more work you do the less improvement you get per unit of work. At some point you establish a cutoff where you're say fixing a bug for every N hours of work. You can predict statistically at that point how often errors will show up in use, but you can't predict where they will show up or what they will be.

Ergo software will be buggy in proportion both to its complexity and to the amount of money spent on SQA. For a commercial enterprise like WotC the question is only how much is the budget for this activity.

Honestly, in my not at all humble because I know about this stuff opinion, the software WotC has produced so far looks pretty much like other fairly young applications which are produced for limited commercial use. They work, they generally do what they are supposed to, and they have a certain number of issues. Nobody LIKES bugs, but they are not something that is a sign of bad development processes. They are simply a result of the finite ability of human beings to understand and test very complex application logic.

 

[Felon]

Really.

How many examples of software releases in the world can you cite that are bug free? Do you believe for even a femtosecond that bugs in software are inevitable? Or do you understand that bugs are simply a cost effective drawback that companies don't iron out because they've created a market condition where consumers will tolerate them?

I have an extremely low tolerance for buggy software and poor website design and implementation. The only reason for it is laziness and incompetence. Companies have somehow duped the public into believing and accepting this status quo, when in fact the reality is that a bug-free application isn't impossible, it's just far more expensive to produce and becomes less cost effective to iron out the bugs than it is to simply lose 0.1% of sales because of people like me.

If people weren't so tolerant of buggy, crappy, amateur-hour efforts, then do you really think that companies would attempt to force such product down our throats? If people didn't buy this stuff, companies would make more of an effort and we'd live in a far less buggy world.

But we don't and so we get things like the Character Builder, Monster Builder, GleeMax and now this weak-sauce VTT. Vote with your wallet by not giving WotC money and you can bet they'll either quit producing low-quality digital content altogether, or they'll up their game and actually make the effort to produce something worth paying for.

I don't know whether to give you a big hug or to give you Biff's George-MacFly treatment. I often think we do live in a world of crumbling standards, where people mistake snideness for wit, inadaptability for strength, and labor under the misconception that self-esteem is a right, not a privilege. But you take the notion of high standards to a bad place.

Sure, many bugs for computer software are inevitable for a mass-release product, particularly one running an an open OS like Windows. You cannot catch them all. That's because there are endless variations of computers running different hardware, different OS's, different browsers, different AVS's, and so forth. This is why game developers have fallen in love with console.

As you say, focusing feverishly on making applications absolutely pristine before release would be extremely expensive. It would also mean very long delays before product release. Both of those are prohibitive factors for most businesses, and I suspect WotC is likely one of them.

To reject what I have just said is to reject reason and pragmatism. That is the distinction between the sort of high standards that place one behind the velvet rope of the select elite and the sort of high standards that induce one to move to a shack in the middle of Montanna after mailing the President of the United States a letter that you are formally seceding your property from the rest of America to form a sovereign nation.

Seriously, I can relate to some degree. I'm playing Civ V right now, and it's got some glaring lack of polish. I'm also playing Fallout New Vegas, and it's riddled with bugs on a vast scale. But I can take into account factors like the time spent of development and the level of ambition displayed, and I wind up forgiving Fallout more than Civ V. Standards should be based upon practical, reasonable criteria, not pie-in-the-sky ideals.

 

[Dice4Hire]

The only thing that proves is that you have (significantly) lower standards than I do.

If people followed my example, then we wouldn't live in a world of buggy, half-arsed, barely out of alpha software, or poorly designed and implemented websites, or Microsoft.

I like my world better.

Perpetual development is less cool than available, if buggy software.

 

[nerfherder]

The upshot is that bugs ALWAYS exist. No piece of software ever written is bug free.

Sorry for being pedantic, because the main thrust of your post is correct, but it is possible to write bug-free code. In 2009, the University of New South Wales took 30 man years to mathematically prove that 7,500 lines of code was bug-free. This, of course, is irrelevant to the issue of the CB, as it will have far more lines of code, use libraries that will have bugs, and sit on an operating system that has bugs. Academically, though, it's interesting.

UNSW: The University of New South Wales - Sydney Australia - News - Code breakthrough delivers safer computing

Code breakthrough delivers safer computing


25th September 2009


Computer researchers at UNSW and NICTA have achieved a breakthrough in software which will deliver significant increases in security and reliability and has the potential to be a major commercialisation success.

Professor Gernot Heiser, the John Lions Chair in Computer Science in the School of Computer Science and Engineering and a senior principal researcher with NICTA, said for the first time a team had been able to prove with mathematical rigour that an operating-system kernel – the code at the heart of any computer or microprocessor – was 100 per cent bug-free and therefore immune to crashes and failures.

The breakthrough has major implications for improving the reliability of critical systems such as medical machinery, military systems and aircraft, where failure due to a software error could have disastrous results.

“A rule of thumb is that reasonably engineered software has about 10 bugs per thousand lines of code, with really high quality software you can get that down to maybe one or three bugs per thousand lines of code,” Professor Heiser said.

“That can mean there are a lot of bugs in a system. What we’ve shown is that it’s possible to make the lowest level, the most critical, and in a way the most dangerous part of the system provably fault free.”

“I think that’s not an exaggeration to say that really opens up a completely new world with respect to building new systems that are highly trustworthy, highly secure and safe.”

Verifying the kernel – known as the seL4 microkernel – involved mathematically proving the correctness of about 7,500 lines of computer code in an project taking an average of six people more than five years.

“The NICTA team has achieved a landmark result which will be a game changer for security-and-safety-critical software,” Professor Heiser said.

“The verification provides conclusive evidence that bug-free software is possible, and in the future, nothing less should be considered acceptable where critical assets are at stake.”

 

[Imaro]

Well, what is it you are saying, that the content of WotC's books should just be 'free game' and everyone who feels like compiling a CB with all that stuff in it is free to do so? I think in some perfect world everything would be Open, but it isn't such a world, so yeah, I can't just go out and make a CB. Actually I CAN but you'll have to figure out how to add all the required data to it. 4e is NO DIFFERENT from any other game in this regard unless said game is being released under something like OGL. Even in the case of Pathfinder you'd have the exact same issues with any content that Paizo created themselves and wasn't copied from the SRD for d20/3.5.

There ARE also quite a few tools that aren't written by WotC. None of them does what CB does, except MAYBE Hero Labs and oddly enough that isn't free either. There are tons of things like macro frameworks, interactive character sheets, files full of NPCs, Master Plan, power card set printing utilities (it will even suck the powers out of Compendium and print the ones you want cards for if you have a DDI sub). There is iplay4e, etc.

Now, I'd love to see WotC declare that they condone all such tools, but since frankly their tools are about as good as anything I've ever seen for ANY game I really am skeptical that it will make a vast difference in quality.

The only valid question is do you feel like the price they charge is worth it to you? Only you can answer that.

Ok, you commmented on the "popularity" of the DDI tools as being indicative in some way of their quality... my couterpoint was that when you don't have much of a choice... popularity does not necessarily, in any way, equate to quality.

 

[heruca]

popularity does not necessarily, in any way, equate to quality.

qft!

 

[Umbran]

Sorry for being pedantic, because the main thrust of your post is correct, but it is possible to write bug-free code.

To be truly pedantic, if I recall correctly, Gödel's incompleteness theorem, and Turing's proof of the unsolvability of the halting problem still stand.

That is to say, you cannot prove, for all possible inputs to a program, that the program will run to completion. Even for "perfect" code that contains no technical errors, there may exist an input for which that code will crash.

 

[nerfherder]

To be truly pedantic, if I recall correctly, Gödel's incompleteness theorem, and Turing's proof of the unsolvability of the halting problem still stand.

That is to say, you cannot prove, for all possible inputs to a program, that the program will run to completion. Even for "perfect" code that contains no technical errors, there may exist an input for which that code will crash.

I will bow to your knowledge being greater than my ability to google

 

[Alan Shutko]

To be truly pedantic, if I recall correctly, Gödel's incompleteness theorem, and Turing's proof of the unsolvability of the halting problem still stand.

That is to say, you cannot prove, for all possible inputs to a program, that the program will run to completion. Even for "perfect" code that contains no technical errors, there may exist an input for which that code will crash.

Not quite. You can't write a generalized algorithm to do this for all potential pairs of programs and inputs. You CAN prove it for many specific programs.

 

[Nagol]

To be truly pedantic, if I recall correctly, Gödel's incompleteness theorem, and Turing's proof of the unsolvability of the halting problem still stand.

That is to say, you cannot prove, for all possible inputs to a program, that the program will run to completion. Even for "perfect" code that contains no technical errors, there may exist an input for which that code will crash.

Turing's halting problem can be sidestepped with a test specific to the algorithm being examined; Turing only showed no general algorithm can exist. Total correctness can be determined.