And in the workplace, which skill is required the more: writing documents or building operating systems? Which do you think is going to be more relevant to the average child when he or she grows up?
If they will move to US? Yes.
Do you really want to teach millions of kids abroad the highly specialized set of skills they only can use to get a secretary job in US? I don't think so.
Listen, you dumbass.
Most countries do not feed massive armies of office drones stuffed into countless office buildings thrown all over the country. They do not have people trying to sell tiny houses built in clumps on 100 in the middle of a fucking desert, for $600000 each to each other until their two "special" mortgage companies go belly up. They do not shut down its industry and get all kinds of crap from China and Korea for free, just racking up trade deficit or "re-selling" its national debt without any intention to pay it back. They do not have farmers who employ exclusively illegal immigrants, farming on the best soil in the world, paying less than minimal wages and no taxes on those workers. They do not pay tens of millions per year to celebrities to hawk brands of consumer products on TV -- products that are produced "for free" and money that got "for free" from an endless loan machine (see above).
They have large -- huge -- numbers of people who DO ACTUAL WORK, MAKING ACTUAL THINGS THEY AND OTHER PEOPLE USE. And they need computers TO ORGANIZE THIS PRODUCTION, TO DESIGN THOSE PRODUCTS, AND TO CONTROL THE TOOLS AND TO BE EMBEDDED INTO PRODUCTS. Microsoft Office DOESN'T DO SHIT for those purposes.
Not anymore. There is a "thin" version of firmware "blob of shit" that allows mesh networking to be implemented in a regular Linux driver, and there is already a drivers that implements it.
Flash installs on XO just fine. It just has to be installed by the user due to licensing crap from Adobe.
However Flash does not work fast enough on XO on Linux or Windows, to be useful for one of its main purposes, viewing video.
This is why months ago I made a package that provides Youtube/Google Video viewer on XO running Ubuntu (that, BTW, I am maintaining). Viewer uses mplayer configured to for reduced CPU performance, and AFAIK, this is the only configuration that plays all Youtube videos properly on XO. It can be adapted for Sugar, too.
Ubuntu also does everything that "bare" Windows will do on XO. OpenOffice.org, Inkscape and Gimp install and work fine, too. Nothing 3D is going to work on XO on any platform due to 2D-only graphics hardware, so 3D games and CAD are out.
While I can't comment on chairs, I am sure, I have seen people surviving watching Uwe Boll movies or spewing Microsoft marketing crap in front of other people.
On the other hand, if there is going to be some public beating of Microsoft marketdroid anywhere near SF Bay Area, count me in.
If absolute perfection is the yardstick you measure by, no wonder you believe most programmers are incompetant.
Lack of this "absolute perfection" is the reason why most of software is chock-full of security bugs. Security is one area where pretty much anything unexpected done by a program as a response for (usually) invalid input results in a massive hole that will be eventually exploited. Developer that relies on tests will never hit those conditions unless tests are developed by someone much smarter than he is (and then why doesn't that smarter person work on the project itself?).
Fortunately the solution is actually simple -- design software in a rule-based manner (so no actual scenario has ever to be considered, only classes of it), with consistent representation of data (so "deep propagation of invalid conditions" such as your example with "None" will never happen), and clearly defined interfaces (so programmer has a limited scope of code to work on, and clearly defined requirements to what it should accept and produce).
OS kernels, servers for all general-purpose open protocols, and other software that is expected to be critical for system security and reliability is usually developed in this manner, and as the result of it, serious security bugs are relatively rare in those types of software. On the other hand, database servers, custom applications, everything "enterprise", everything desktop, web browsers, etc. -- all software that is developed by amateurs or amateur-level developers working for software-only companies -- has massive amounts of ridiculously trivial security bugs because programmers working on that type of projects are completely unfamiliar with those principles, yet seem to know everything about excessive testing and "perma-debugging" cycle.
If you're refactoring a large application,
...it means, you are fixing someone else's major mistakes by writing new code that imitates all minor mistakes that he made, to provide bug-for-bug compatibility with an interface designed around that code.
If interface was clearly defined and made sense, you would not have to "refactor" anything, you either keep old code because it isn't broken, or reimplement its functionality using whatever means that became available. Again, this is how everything works with open protocols and APIs, there is no reason not to follow the same principles everywhere else.
tracking every possible result of each alteration by hand is impractical and inefficient.
Alteration of what? Programmer should avoid changing existing code, things should be either replaced (if they are inadequate) or added using existing interfaces (if new functionality should be added to existing piece of software).
Far better to use unit tests and compile time checks to ensure correctness, as a thousand automated tests are going to be less prone to error than checking a thousand things by hand.
And all actually dangerous bugs will be still there because they are outside of the scope of testing. And some bugs will be introduced as a result of bugs in the tests (no one said that tests are less buggy than the code they test -- they are written by the same idiot using the same poor understanding of the problem, and you can't test a test, so bugs in tests stay forever).
Only if the programmer is a complete incompetent, but you don't need to be a complete incompetent for there to be bugs in your code.
Most of programmers are incompetent. Few programmers that are competent know better than to rely on compiler to fish for bugs in their code.
Similarly, you'd have to explicitly tell Haskell that the distance to an object was 'Maybe Float' metres, rather than just 'Float' metres. It would require a really enterprising idiot to work around the typing errors without once engaging his brain.
...and since there are thousands or tens of thousands of functions that will end up processing those values, most of them will call a single "default error handler" function when encountering such a value. The handler will display a generic error message and terminate the program. This is how this "problem" started in the first place -- proper error handling was too unwieldy, so people "simplified" it with exceptions. The core of the issue remained -- when programmer does not think of how a program should react to something, program does something stupid.
Compile-time checks aren't a complete solution, but to claim that they won't have any effect at all seems silly.
Those are the kind of improvements that I describe as "If this actually managed to help you, you were not qualified to do this job in the first place". If programmer does not consider full set of possible outcomes of all situations, he can't write a program that properly handles it. If compiler throws some of those outcomes in his face, there will be still plenty of ones he did not take into account because they are only "wrong" or "invalid" according to some data model that programmer has in his head (and hopefully in documentation) but do not break anything that compiler handles. Compiler will not help with that.
This still does very little to reduce the number of actual bugs -- in your example if programmer does not know what to do when he gets None, he will still do something invalid down the line when he applies it to some other operations (like, skipping None lines in the input file when formatting it for printing, or waiting None seconds before dialing the phone number, or allocating None IP addresses for some devices, or measuring the distance to an object None meters tall using a camera image where it takes 20 pixels). Oh, sure, he will have to allow this as an input value, he just won't make it perform the right action, and the source of the problem is likely way before the point in the program where it avoided divide by zero.
When dealing with more complex programs, and especially with finite resources (when you can get an error as a result of perfectly valid input), this does not help at all.
If you have no idea what I'm talking about, why are you arguing the opposite view instead of asking me what I meant?
Because I can narrow it down to a set of meanings -- and it is inside the set of stupid ideas.
I'll give you an example. The Java compiler cannot guarentee that a program will not raise a NullPointerException during its execution. In contrast, the Glasgow Haskell Compiler can guarentee that no null references will ever exist if the program passes compilation.
And I can "solve" a halting problem by inventing a language that runs all programs in a loop, so they can't halt.
This is not a property of compiler, it's a property of language. Language is not defined by "compiler checks", it determines what compiler does in the first place.
Any system has some range of conditions that it is intended to tolerate, and there is always a possibility that something outside of that range will break it. As long as people who use and run those systems are aware of this, there is no point in reporting "vulnerabilities" of this kind, in 16-page papers or otherwise. I am sure, I can get a bulldozer, add some armor made of steel and concrete, drive it into a data center, and cause a massive denial of service for everything in it. And yet this is not a good reason to write papers on killdozer-proofing data centers, and neither I would expect an experimental verification of this fact to be appreciated by its victims.
This is actually a much wider problem. For exactly the same reason airport security madness is counterproductive -- a determined person still can destroy an airplane with its passengers, however millions of people suffer from pointless "security measures" that produce no positive outcome. While being as clueless about security as American politicians is not a crime, this student has very poor understanding of the very subject of his paper.
So you're saying that tougher compile time checks would make inept programmers more productive, but not reduce their bug count.
I am talking about languages that don't have features that are considered bug-prone, such as pointers, user-controlled memory management, variable type conversion, etc. I have no idea, what do you mean by "tougher compile-time checks" -- if the compiler does not produce an error on invalid source, it's a buggy compiler. Compiler second-guessing the programmer can catch some obvious typos, however if those bugs are present in a program, it usually means that the programmer is not ready to write production code in the first place.
Unless you're proposing that inept programmers deliberately insert bugs into their code, I'm uncertain how you reached this conclusion.
They lack fundamental knowledge of the mechanisms they are using, and have no intention to obtain it. They use a trial-and-error method that I call "perma-debugging" -- writing code that seems right, compiling it, making random changes until it compiles, running it on some test input, making random changes until the test runs, writing more code and repeating the process. The result of this process is your typical buggy piece of software.
People actively AVOID getting into an accident, so while it's still possible to die horribly in all kinds of ways, a person will not likely to get to the point of actually getting into a fatal accident unless something is seriously broken (say, railing is unexpectedly missing on a bridge).
Inexperienced and stupid programmers produce bugs at nearly constant rate -- give them something that makes some bugs impossible, and they will either improve their productivity (still with $deity-awful rate of bugs), or start making different kinds of bugs.
I wasn't clear in that when I previously used the word "direct" I didn't mean "a direct cause", I was just stating that the connection between the Earth and Sun was a direct connection, as opposed to all implied indirectness of the watered down semantics used by scientists too afraid to admit that there is electricity in space.
As far as the cause, I meant to imply that these changes in the electromagnetic forces alter something else that we don't fully understand, even though we thought we did because of how (relatively) constant these forces have averaged in our extremely short time observing them.
That's why you don't just have a test group, you also have test specifications and test specifications reviews. It's meant to be a team effort you know, not just a prima donna programmar whining at the test group due to a test specification that was pulled out of thin air. If the developer actually had a clue and cared about quality he'd have fixed the process.
That assumes that people can agree on what specification should be. You are EXTREMELY LUCKY when you can reach some agreement about interface in a reasonable time, however with internals and mechanisms (that in theory can benefit from testing) it's usually easier to write bug-free code than to bring together programmers working on different projects and get them to agree on what each other is doing.
It sounds like you've only works on systems (however complex you thought they were) at the low end of the complexity scale, probably ones who's interactions with external systems out of your control was limited or non-existant.
Thank you for preemptively dismissing my refutation of this. Too bad, nothing verifies the applicability of your attitude.
Actually it was a very complex system in itself, and it had to interact with various systems both developed internally and externally. It was a great success when it was possible to split the project into parts with clearly defined interface, so things actually could work together instead of constantly getting readjusted to follow evolution of internals -- and even then most of developers had serious misunderstandings of what those specifications actually mean beyond their own parts of the project. Any attempt to bring them closer together would completely halt the development, and those were relatively sane and competent developers in the first place.
"Exessive amounts" of test cases are necessary when there are "exessive amounts" of input conditions which should generate different system respones. The Telecom system I am working on right now has a (fully automated) regression test suite of many thousands of test cases.
Only thousands???? In telecom??? BWAHAHAHAHAHAHAHAHAHAHAHAHA!
In a system I was talking about (that was also telecom-related) the bugs only started to crawl out when relationships between objects and states of protocols created an equivalent of M.C. Escher drawing. "Thousands" was what testers thought, they can get away with. The solution was to treat the whole thing like a language and "parse" combinations and sequences of actions. To generate an exhaustive test case would be nearly infeasible if all interfaces were formally specified and kept up to date, and since they weren't, the only way to make sure that things worked was to approach this as a language processing in general, trust the model to be correct, and do testing only to check for obvious implementation failures.
When I worked as a developer for a software-only company, it never ever happened that an actual bug was found by testers -- all I got from them was false positives that shown flawed assumptions in their test methodology that I had to waste my time refuting. All actual bugs were found either by developers doing their own analysis of the code (when not swamped by false positives from above mentioned testers) or at the customers' sites where it was usually discovered that some fundamental assumption about the environment was completely wrong.
Code reviews were impossible because of lack of time, over-inflated egos and politics.
The only things that actually improved quality were situations when a developer was able to request three-weeks "no-bugfixes" period that he could spend rewriting obsolete parts of software, thus reducing the amount of kludges that were both the original source of bugs, and result of "bugfix-driven" development.
I can imagine a situation when excessive amount of tests and testers are useful, and that situation is when developers are so incompetent, all bugs are trivial, and all nontrivial bugs are acceptable. Then, of course, they can continue banging at keyboards producing code that vaguely corresponds to their understanding of the software purpose, adding random changes added until it passes the test. To think of it, this explains a lot about some software, and about some programmers I have seen.
Go read up on the Capability Maturity Model (CMM) or ISO 9000 and come back when you have a clue.
Do you really think, anyone actually does that according to any kind of standard? In reality all those things are whatever developers, managers and testers implemented. Most of it is incapable of catching bugs and problem in any way other than by accident.
Of course, games are art -- art is anything that is produced to express something, without some primary utilitarian purpose. Most of games aren't good art, but neither are most paintings or most movies.
As for the expression of ideas -- all games that simulate a behavior of a person in some kind of social situation depict some kind of society and reflect some system of values that in its turn is based on some kind of ideology. People only care about this when the ideology expressed conflicts with their own one, however this has nothing to do with the fact that expression is always there.
No one has any "quality control procedures" in software. At best a company has someone responsible for testing, and some product-specific set of tests that products pass through before being released or placed into production environment. If you are a developer, just make those things and write a deployment procedure that includes them.
Slashdot Mirror
And in the workplace, which skill is required the more: writing documents or building operating systems? Which do you think is going to be more relevant to the average child when he or she grows up?
If they will move to US? Yes.
Do you really want to teach millions of kids abroad the highly specialized set of skills they only can use to get a secretary job in US? I don't think so.
Listen, you dumbass.
Most countries do not feed massive armies of office drones stuffed into countless office buildings thrown all over the country. They do not have people trying to sell tiny houses built in clumps on 100 in the middle of a fucking desert, for $600000 each to each other until their two "special" mortgage companies go belly up. They do not shut down its industry and get all kinds of crap from China and Korea for free, just racking up trade deficit or "re-selling" its national debt without any intention to pay it back. They do not have farmers who employ exclusively illegal immigrants, farming on the best soil in the world, paying less than minimal wages and no taxes on those workers. They do not pay tens of millions per year to celebrities to hawk brands of consumer products on TV -- products that are produced "for free" and money that got "for free" from an endless loan machine (see above).
They have large -- huge -- numbers of people who DO ACTUAL WORK, MAKING ACTUAL THINGS THEY AND OTHER PEOPLE USE. And they need computers TO ORGANIZE THIS PRODUCTION, TO DESIGN THOSE PRODUCTS, AND TO CONTROL THE TOOLS AND TO BE EMBEDDED INTO PRODUCTS. Microsoft Office DOESN'T DO SHIT for those purposes.
Not anymore. There is a "thin" version of firmware "blob of shit" that allows mesh networking to be implemented in a regular Linux driver, and there is already a drivers that implements it.
Flash installs on XO just fine. It just has to be installed by the user due to licensing crap from Adobe.
However Flash does not work fast enough on XO on Linux or Windows, to be useful for one of its main purposes, viewing video.
This is why months ago I made a package that provides Youtube/Google Video viewer on XO running Ubuntu (that, BTW, I am maintaining). Viewer uses mplayer configured to for reduced CPU performance, and AFAIK, this is the only configuration that plays all Youtube videos properly on XO. It can be adapted for Sugar, too.
Ubuntu also does everything that "bare" Windows will do on XO. OpenOffice.org, Inkscape and Gimp install and work fine, too. Nothing 3D is going to work on XO on any platform due to 2D-only graphics hardware, so 3D games and CAD are out.
Another Microsoft employee found.
Despite the clear denials someone keeps spreading rumours the OLPC has replaced or partially replaced Linux with Windows.
And this was mean very little if that "someone" was not Nicholas Negroponte himself.
At various occasions he claimed:
1. OLPC is "working with Microsoft" (true).
2. SD card was added to XO to allow booting Windows (lie, denied by hardware developers themselves).
He also called Open Source developers "fundamentalists" and implied that their participation in OLPC project is counterproductive.
Good luck on getting fixes for a 13 year old Linux distribution.
All Linux distributions that existed 13 years ago can be upgraded to the current versions (along with all software and users' settings).
Of course, being one of many Microsoft marketing people in this thread you can't know this.
While I can't comment on chairs, I am sure, I have seen people surviving watching Uwe Boll movies or spewing Microsoft marketing crap in front of other people.
On the other hand, if there is going to be some public beating of Microsoft marketdroid anywhere near SF Bay Area, count me in.
If absolute perfection is the yardstick you measure by, no wonder you believe most programmers are incompetant.
Lack of this "absolute perfection" is the reason why most of software is chock-full of security bugs. Security is one area where pretty much anything unexpected done by a program as a response for (usually) invalid input results in a massive hole that will be eventually exploited. Developer that relies on tests will never hit those conditions unless tests are developed by someone much smarter than he is (and then why doesn't that smarter person work on the project itself?).
Fortunately the solution is actually simple -- design software in a rule-based manner (so no actual scenario has ever to be considered, only classes of it), with consistent representation of data (so "deep propagation of invalid conditions" such as your example with "None" will never happen), and clearly defined interfaces (so programmer has a limited scope of code to work on, and clearly defined requirements to what it should accept and produce).
OS kernels, servers for all general-purpose open protocols, and other software that is expected to be critical for system security and reliability is usually developed in this manner, and as the result of it, serious security bugs are relatively rare in those types of software. On the other hand, database servers, custom applications, everything "enterprise", everything desktop, web browsers, etc. -- all software that is developed by amateurs or amateur-level developers working for software-only companies -- has massive amounts of ridiculously trivial security bugs because programmers working on that type of projects are completely unfamiliar with those principles, yet seem to know everything about excessive testing and "perma-debugging" cycle.
If you're refactoring a large application,
...it means, you are fixing someone else's major mistakes by writing new code that imitates all minor mistakes that he made, to provide bug-for-bug compatibility with an interface designed around that code.
If interface was clearly defined and made sense, you would not have to "refactor" anything, you either keep old code because it isn't broken, or reimplement its functionality using whatever means that became available. Again, this is how everything works with open protocols and APIs, there is no reason not to follow the same principles everywhere else.
tracking every possible result of each alteration by hand is impractical and inefficient.
Alteration of what? Programmer should avoid changing existing code, things should be either replaced (if they are inadequate) or added using existing interfaces (if new functionality should be added to existing piece of software).
Far better to use unit tests and compile time checks to ensure correctness, as a thousand automated tests are going to be less prone to error than checking a thousand things by hand.
And all actually dangerous bugs will be still there because they are outside of the scope of testing. And some bugs will be introduced as a result of bugs in the tests (no one said that tests are less buggy than the code they test -- they are written by the same idiot using the same poor understanding of the problem, and you can't test a test, so bugs in tests stay forever).
Ok.
That's no planet...
Only if the programmer is a complete incompetent, but you don't need to be a complete incompetent for there to be bugs in your code.
Most of programmers are incompetent. Few programmers that are competent know better than to rely on compiler to fish for bugs in their code.
Similarly, you'd have to explicitly tell Haskell that the distance to an object was 'Maybe Float' metres, rather than just 'Float' metres. It would require a really enterprising idiot to work around the typing errors without once engaging his brain.
...and since there are thousands or tens of thousands of functions that will end up processing those values, most of them will call a single "default error handler" function when encountering such a value. The handler will display a generic error message and terminate the program. This is how this "problem" started in the first place -- proper error handling was too unwieldy, so people "simplified" it with exceptions. The core of the issue remained -- when programmer does not think of how a program should react to something, program does something stupid.
Compile-time checks aren't a complete solution, but to claim that they won't have any effect at all seems silly.
Those are the kind of improvements that I describe as "If this actually managed to help you, you were not qualified to do this job in the first place". If programmer does not consider full set of possible outcomes of all situations, he can't write a program that properly handles it. If compiler throws some of those outcomes in his face, there will be still plenty of ones he did not take into account because they are only "wrong" or "invalid" according to some data model that programmer has in his head (and hopefully in documentation) but do not break anything that compiler handles. Compiler will not help with that.
This still does very little to reduce the number of actual bugs -- in your example if programmer does not know what to do when he gets None, he will still do something invalid down the line when he applies it to some other operations (like, skipping None lines in the input file when formatting it for printing, or waiting None seconds before dialing the phone number, or allocating None IP addresses for some devices, or measuring the distance to an object None meters tall using a camera image where it takes 20 pixels). Oh, sure, he will have to allow this as an input value, he just won't make it perform the right action, and the source of the problem is likely way before the point in the program where it avoided divide by zero.
When dealing with more complex programs, and especially with finite resources (when you can get an error as a result of perfectly valid input), this does not help at all.
If you have no idea what I'm talking about, why are you arguing the opposite view instead of asking me what I meant?
Because I can narrow it down to a set of meanings -- and it is inside the set of stupid ideas.
I'll give you an example. The Java compiler cannot guarentee that a program will not raise a NullPointerException during its execution. In contrast, the Glasgow Haskell Compiler can guarentee that no null references will ever exist if the program passes compilation.
And I can "solve" a halting problem by inventing a language that runs all programs in a loop, so they can't halt.
This is not a property of compiler, it's a property of language. Language is not defined by "compiler checks", it determines what compiler does in the first place.
Any system has some range of conditions that it is intended to tolerate, and there is always a possibility that something outside of that range will break it. As long as people who use and run those systems are aware of this, there is no point in reporting "vulnerabilities" of this kind, in 16-page papers or otherwise. I am sure, I can get a bulldozer, add some armor made of steel and concrete, drive it into a data center, and cause a massive denial of service for everything in it. And yet this is not a good reason to write papers on killdozer-proofing data centers, and neither I would expect an experimental verification of this fact to be appreciated by its victims.
This is actually a much wider problem. For exactly the same reason airport security madness is counterproductive -- a determined person still can destroy an airplane with its passengers, however millions of people suffer from pointless "security measures" that produce no positive outcome. While being as clueless about security as American politicians is not a crime, this student has very poor understanding of the very subject of his paper.
...And this is why Libertarians are best friends and servants of Republicans, Social Conservatives and similar scum.
So you're saying that tougher compile time checks would make inept programmers more productive, but not reduce their bug count.
I am talking about languages that don't have features that are considered bug-prone, such as pointers, user-controlled memory management, variable type conversion, etc. I have no idea, what do you mean by "tougher compile-time checks" -- if the compiler does not produce an error on invalid source, it's a buggy compiler. Compiler second-guessing the programmer can catch some obvious typos, however if those bugs are present in a program, it usually means that the programmer is not ready to write production code in the first place.
Unless you're proposing that inept programmers deliberately insert bugs into their code, I'm uncertain how you reached this conclusion.
They lack fundamental knowledge of the mechanisms they are using, and have no intention to obtain it. They use a trial-and-error method that I call "perma-debugging" -- writing code that seems right, compiling it, making random changes until it compiles, running it on some test input, making random changes until the test runs, writing more code and repeating the process. The result of this process is your typical buggy piece of software.
Constant bugs rate means that number of bugs increases with productivity, and products remain just as buggy.
People actively AVOID getting into an accident, so while it's still possible to die horribly in all kinds of ways, a person will not likely to get to the point of actually getting into a fatal accident unless something is seriously broken (say, railing is unexpectedly missing on a bridge).
Inexperienced and stupid programmers produce bugs at nearly constant rate -- give them something that makes some bugs impossible, and they will either improve their productivity (still with $deity-awful rate of bugs), or start making different kinds of bugs.
China's GDP is about 1/4 ours
You mean, when a product is made in China and sold in US, American companies make 4 times of what Chinese made on it?
Checking the asylum... HOLY SHIT, pettan-pettan is missing!
I wasn't clear in that when I previously used the word "direct" I didn't mean "a direct cause", I was just stating that the connection between the Earth and Sun was a direct connection, as opposed to all implied indirectness of the watered down semantics used by scientists too afraid to admit that there is electricity in space.
As far as the cause, I meant to imply that these changes in the electromagnetic forces alter something else that we don't fully understand, even though we thought we did because of how (relatively) constant these forces have averaged in our extremely short time observing them.
What would we all do without that biting pear?..
That's why you don't just have a test group, you also have test specifications and test specifications reviews. It's meant to be a team effort you know, not just a prima donna programmar whining at the test group due to a test specification that was pulled out of thin air. If the developer actually had a clue and cared about quality he'd have fixed the process.
That assumes that people can agree on what specification should be. You are EXTREMELY LUCKY when you can reach some agreement about interface in a reasonable time, however with internals and mechanisms (that in theory can benefit from testing) it's usually easier to write bug-free code than to bring together programmers working on different projects and get them to agree on what each other is doing.
It sounds like you've only works on systems (however complex you thought they were) at the low end of the complexity scale, probably ones who's interactions with external systems out of your control was limited or non-existant.
Thank you for preemptively dismissing my refutation of this. Too bad, nothing verifies the applicability of your attitude.
Actually it was a very complex system in itself, and it had to interact with various systems both developed internally and externally. It was a great success when it was possible to split the project into parts with clearly defined interface, so things actually could work together instead of constantly getting readjusted to follow evolution of internals -- and even then most of developers had serious misunderstandings of what those specifications actually mean beyond their own parts of the project. Any attempt to bring them closer together would completely halt the development, and those were relatively sane and competent developers in the first place.
"Exessive amounts" of test cases are necessary when there are "exessive amounts" of input conditions which should generate different system respones. The Telecom system I am working on right now has a (fully automated) regression test suite of many thousands of test cases.
Only thousands???? In telecom??? BWAHAHAHAHAHAHAHAHAHAHAHAHA!
In a system I was talking about (that was also telecom-related) the bugs only started to crawl out when relationships between objects and states of protocols created an equivalent of M.C. Escher drawing. "Thousands" was what testers thought, they can get away with. The solution was to treat the whole thing like a language and "parse" combinations and sequences of actions. To generate an exhaustive test case would be nearly infeasible if all interfaces were formally specified and kept up to date, and since they weren't, the only way to make sure that things worked was to approach this as a language processing in general, trust the model to be correct, and do testing only to check for obvious implementation failures.
When I worked as a developer for a software-only company, it never ever happened that an actual bug was found by testers -- all I got from them was false positives that shown flawed assumptions in their test methodology that I had to waste my time refuting. All actual bugs were found either by developers doing their own analysis of the code (when not swamped by false positives from above mentioned testers) or at the customers' sites where it was usually discovered that some fundamental assumption about the environment was completely wrong.
Code reviews were impossible because of lack of time, over-inflated egos and politics.
The only things that actually improved quality were situations when a developer was able to request three-weeks "no-bugfixes" period that he could spend rewriting obsolete parts of software, thus reducing the amount of kludges that were both the original source of bugs, and result of "bugfix-driven" development.
I can imagine a situation when excessive amount of tests and testers are useful, and that situation is when developers are so incompetent, all bugs are trivial, and all nontrivial bugs are acceptable. Then, of course, they can continue banging at keyboards producing code that vaguely corresponds to their understanding of the software purpose, adding random changes added until it passes the test. To think of it, this explains a lot about some software, and about some programmers I have seen.
Go read up on the Capability Maturity Model (CMM) or ISO 9000 and come back when you have a clue.
Do you really think, anyone actually does that according to any kind of standard?
In reality all those things are whatever developers, managers and testers implemented. Most of it is incapable of catching bugs and problem in any way other than by accident.
Of course, games are art -- art is anything that is produced to express something, without some primary utilitarian purpose. Most of games aren't good art, but neither are most paintings or most movies.
As for the expression of ideas -- all games that simulate a behavior of a person in some kind of social situation depict some kind of society and reflect some system of values that in its turn is based on some kind of ideology. People only care about this when the ideology expressed conflicts with their own one, however this has nothing to do with the fact that expression is always there.
No one has any "quality control procedures" in software. At best a company has someone responsible for testing, and some product-specific set of tests that products pass through before being released or placed into production environment. If you are a developer, just make those things and write a deployment procedure that includes them.