Just a little while ago, I was reading about the
Infinite Monkey Theorem, as a means of providing input to software tests, on Wikipedia that states: "a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type a particular chosen text, such as the complete works of william Shakespeare."
The explanation of the theorem clarifies that the behavior of the "monkey" is assumed to be something that can generate characters randomly. Stating that particular assumption does tend to pacify critics trying to discredit the theorem.
If you've observed child behavior, they initially repeat whatever seems to interest them. If they pressed the space bar and found the sound made by the keyboard interesting, they would continue to press the space bar to boredom. They will then try out some other keys at the center of the keyboard, or perhaps some toward the left and right edges too but they wouldn't usually get to the upper edge since those are farther away and less likely to be pressed... unless they push the keys in sequence (1, 2, 3, 4, 5, 6, 7, 8, 9, 0...) but that isn't random.
My nephew eventually got tired of pushing keys on the keyboard so the "infinite amount of time" part may be hard to test. He pushes the power button now because it gets the hard disk LED flashing and then eventually turns all the LEDs off :-(
When building systems, we've always got to watch out for the infamous 'Napkin specification'. This kind of spec looks good and simple, but when you start to build you would notice some detail missing.
For instance, consider a case where you're building the user interface for an application using a user interface wireframe and the business components have already been provided to you. At first glance, you might think, "How hard can it be? We've already got the screen design and have the business components built." As development begins, you start to build the user interface by disabling buttons that the user should not have access to (for whatever reason) and when you're demo-ing the system to the customer, the customer asks why the buttons are even on the screen when the user shouldn't be able to use them.
I wouldn't say there was no design here - there was a design specifying which screen element should go where, but there was no specification for the behavior of the elements. How much data should be allowed in a particular field before displaying an error to the user? What kind of data is considered invalid? For some people, "cooldude@localhost" is a perfectly valid email address but others would want a check for a dot in the domain name.
Visual Studio 2005 SP1 added in a couple of _designer:wfdid attributes into some of my ASP.NET tags and they prevent the project from compiling. Apparently, there's a bug somewhere that didn't get fixed with the service pack.
Removing the attribute fixed the compilation error.