In my mind, the big failure was that we didn't replace the dollar with coins, we added new dollar coins and kept the dollar bill in circulation. Inertia was enough to doom the changeover.

The benefits of the change mostly accrue to the government - coins last an order of magnitude longer, but aren't that much more expensive to produce. From the consumer perspective it is not obvious that one is preferable to the other, so why bother to switch?

Don't forget that over the last 40 years your taste buds have been - we'll say changing, because that sounds better than deteriorating - so even identical foods today probably don't taste like they did 40 years ago.

Aging sucks, and your taste buds are not exempt.

I am in complete agreement that there are many bad patents out there. But at the same time, many novel and non-obvious patents become completely obvious once you see them. If you see the solution and immediately know how to recreate it yourself, that does not says that the initial implementation of it was obvious.

Until source control systems work on semantics and not textual diffs, it is not as simple as that. If I get your code, reformat it to my style, change 2 lines and check it back in, I have completely polluted it as far as a diff goes.

If you want to have a rule that says all code gets run through a formatter prior to check-in, that would work, but it would mean that everyone would spend lots of time converting to and from the approved check in style.

Disclosure: I used to work for a company owned by Pearson.

$120 for a test is very much the reality of clinical testing. The research, norming and validation of the test are not cheap, and while I don't know anything about this particular test, instruments like this are normally developed and refined over multiple years of research. You are talking about lots of administrations in clinical settings, and follow ups to determine the eventual outcome of the patient. And research papers in peer reviewed journals to convince people in the industry that you have statistically valid results.

And any clinical test has a small market, since the number of people that can use it is relatively small. And usually getting paid by health insurance to boot.

I doubt anybody has any illusions that it is foolproof. Same as DRM in music/video/software isn't expected to stop everything. The intent is to put enough roadblocks in front of people that the average person doesn't bother to circumvent them. Total compliance isn't necessary. iTunes and Amazon sell MP3 tracks that could easily be found on line, but it is cheap enough and easy enough that people still buy from them. Consoles can be modded to play cracked games, but it is enough of a pain that most people don't bother.

Reducing Office suites to text editing is ridiculous. For most people in an office setting, Word, Excel and PowerPoint are utterly core technologies, and spending a few hundred dollars per seat is a complete non-factor for any medium to large business.

If Unix ran MS-Office, I that many businesses would find it easier to switch away from Windows but still keep Office.

My assumption is that an organization that doesn't have source control doesn't have a deployment process. So yes, he is doing shipping builds on his workstation. If you aren't checking code in, chances are you don't have a build machine either.

Bingo. Source control is an unalloyed good thing, but only if everyone is using it. All it takes is one influential holdout to bollix it up. Suppose that in an effort to get everything into a repository you do lots of work to ensure that the current production code is checked in. But a very senior, highly trusted developer has no interest in using it, so continues developing code from his personal workstation, never committing changes. Now he is on vacation, a bug pops up, someone else innocently goes to the repository, fixes and deploys the code, and loses a bunch of changes that the aforementioned highly respected engineer has already deployed. Customers are screaming, and the engineer blames the source control system (totally unfairly). Now the seed of doubt is planted in managements mind, and everybody is yelling at everybody else.

Source Control is an easy thing to sell to developers once you use it at all. But it only works if everybody is on board.

Perhaps so that the non-coder gets to feel that special cold sweat that comes right as a deployment happens and you start to wonder about all the test cases that weren't in your test plan.

Or perhaps part of this is to give the non-coders an appreciation of how their testing and promotion process prevents buggy code from hitting production, and why changes can't be turned around in a day.

A case of correlation not causation, but even if it is causation, so what? Say Stalin murdered 20 million people in the name of Atheism - how does that in any way constitute an argument for against the existence of god/gods?

Again, so what? I see debates about god get bogged down into non-sequiters like this all the time. Even if we could prove that if everyone believed in God we would all fart rainbows and live happily ever after, that is an argument about the beneficial impact of believing in a god, not a logical argument for the existence of a god.

You make very valid points about where training/equipment crosses the line into cheating, but the part about "when done professionally it is not dangerous" is incorrect. A number of pro cyclists have died from heart issues, and there is at least some belief that EPO use is implicated. I don't know how credible the allegations are regarding EPO, but certainly overuse of steroids comes with very serious side effects.

How can D3 possibly show that this does not work? Major publisher releases highly anticipated sequel, discloses in advance that an always on connection would be required, and despite raging flamewars and trollfests on gaming forums everywhere, sells millions of copies. And so far as I have heard, nobody has cracked it yet so Blizzard's piracy rate is roughly zero.

If I were a game publisher/developer/designer, and my game had a piracy problem, I would latch on to that model in a heartbeat.

Seems more complicated in real life - my car has a very nice display in the dash, primarily for the nav system. But that is also where I check the oil, and the tire pressure, and change various settings. So the display and its associated controls are shared devices. To keep the isolation you want the interface between the devices has to be broader, increasing the attack surface, or you need to find room for a whole bunch of controls, instead of using the very nice display already in the vehicle.

The usual way I explain it to students/non-technical outsiders is that much of my job consists of solving what we used to call "word problems" or "story problems". So nobody tells me that I need to solve 3x + x = 12, but in the course of analysis I discover what that is indeed one of the equations involved.

Boolean logic and basic algebra (and arithmetic of course) are absolute requirements in most programming jobs in my experience, but anything beyond that is more of a specialty requirement.