I found this in a rather old book in the library, it sounds remarkably similar to parts of what the TDD / Test First people are saying now:
Another well-known psychological bias in observation is the overdependence on "early" data returns. In program testing, the programmer who gets early "success" with his program is likely to stop testing too soon. One way to guard against this mistake is to prepare the tests in advance of testing and, if possible in advance of coding. We refer here to tests concerned with detecting the presence of errors -- not to all tests. Obviously, we cannot construct tests in advance for locating the source of an error; nor can we construct the procedures for correcting the error once it has been found. But all testing begins with detection, so advance work of test cases is never wasted -- unless we yield to the temptation to bypass the remaining tests in view of the "excellent" results we have so far.
The debugging system could help us to resist this temptation by forcing us to specify in advance the amount of testing we plan to do. Failure to complete this number of tests could result in a management report, or some other form of prodding to the programmer. In general, of course, anything in the testing system that simplifies the preparation and execution of test cases will help the programmer to overcome the temptation to quit too soon. One such system in use today is particularly designed to counteract the temptation to skip retesting when a "small" change has been made to the program. If the test cases are stored in the system and can be rerun automatically on demand, the programmer is less likely to skip the retest. The typical system of this sort, however, produces vast amounts of output. It is hardly useful to rerun test cases if nobody looks at the results of the rerun. A great improvement could be wrought in these systems by providing automatic comparison between old results and new ones, thus calling the programmer's attention only to those cases that differ from one run to the next.
-- "The Psychology of Computer Programming", Copyright 1971
Most current energy sources have significant problems, which will make them less and less usable as energy needs and environmental restrictions continue to advance. Even most so-called "green" or "renewable" energy sources cannot be made viable as long-term solutions, simply because they depend on sunlight as the origin of the energy that they provide.
Given that sunlight provides about 1kW/sq. yard, and the radius of the earth is about 6400 km, the maximum possible output of these "green" power sources is about 150000 terawatts. Given a world population of about 6 billion, this works out to about 25 MW per person. Now considering that the reason these power sources are considered "green" is that they don't have a substatial impact on the environment it becomes clear that not even a percent of this maximum output can be realized while maintaining this "green" status -- let's assume 0.01% coverage is acceptable, so the output can be up to 2.5 kW per person.
Now consider that charging an electric car takes about 1.2 MW, and driving it will use about 12.5 kW -- simply driving takes 5x the available energy for one person! Clearly, current "green" power is not a long-term solution.
Fossil fuels can provide higher power for a short time, as the act more as large energy reserivoirs which have been filled over the past few thousand years; however, there are two major problems: they cannot provide long-term power because those reerivoirs will quickly become depleted, and they are commonly understood to harm the environment (as well as being generally stinky and unpleasant to live near).
Current possibilities are nuclear and geothermal power. It is not currently known how scalable geothermal power is; perhaps it can scale to the required total power, perhaps not. Additionally, geothermal power requires that the local geography be at least somewhat cooperative.
The best currently known solution is nuclear. Waste doesn't have to be a problem, as you can either reprocess it to extract the valuble component elements (some of which can even be re-used as fuel again), or sell it to someone who wishes to use it. New plants can be built wherever there is sufficient water; on coastlines or at see, or on major rivers. Smaller single-community sized plants could likely even be built near small rivers, or perhaps even large streams.
The alert provides a web form to write to your congress person. Please do that. And please put the alert up elsewhere, so that other people can help too.
I'm in Washington DC working on this today, and your support will help.
I'd really appreciate it if you'd create a login on the site and submit articles. Especially original work, which hasn't always been well recieved on Slashdot - they seem to prefer linking to other people's coverage. RDF and RSS are available at http://technocrat.net/rdf and http://technocrat.net/rss, so you can keep track of articles from elsewhere.
My most recent episode was at the 9000 foot visitor station on Mauna Kea. The folks there said that I shouldn't attempt to drive up to the telescopes without a 4-wheel-drive vehicle. So, I went in the parking lot and accosted occupants of the first 4-wheel-drive vehicle that came by. The driver of said vehicle had seen me lecture in San Francisco. I got my ride.
Just by standing at that 9000 foot visitor station, I'd passed through the nerd filter.
Then, a few weeks ago, I happened to come upon a local radio club's ham radio field day operation while hiking in the woods with my wife. An co-worker from 10 years ago walked up. It turned out he'd just gotten his ham license.
This stuff happens all of the time. Of course it helps that I am somewhat recognizable in tech circles, so people who know of me tend to walk up, but on the other hand I am not that well known.
What are your experiences beyond the nerd filter?
I wonder what would happen in case of a subpoena or other such judicial order?
So, word to the wise: please be careful when you post something as AC, because it is most definitely not anonymous.
The absence of labels [in ECL] is probably a good thing. -- T. Cheatham