Hi Woz, Decades ago in Houston, I got called in to modify a 4-channel strip chart recorder program running on an Apple ][ motherboard stuffed into an industrial chassis.I asked for the source code and was given a small notebook with some hand-written and hand-assembled 6502 code that you had written. The story I got was that Hillel, the manager in charge, had gone to a computer show back in around 1977 or so and had seen the hardware capabilities of the Apple ][. He apparently said he'd order a bunch of boards if someone would write a program to display the data. He designed a small board with some A/D converters to connect to some pipe inspection machines. Someone volunteered you to do the programming. According to the legend, you kept putting him off until he finally came out and camped on your doorstep one weekend while you wrote the program.

What do you remember about this?

I added some new functionality to the program; I think the first thing I did was to add 2 more channels, then added code to record the results to a digital cassette. It eventually grew to more than I could fit into 16K of ROM and needed more than 320 lines of video and I ported it to some 8086-type machine. I think the last time I worked on it, I had it up to 10 channels with lots of configuration options. I got 7 or 8 years of contracting out of that program. I also remember learning quite a lot about how to inventively use the 6502, some of which I was able to use on later projects.

Did no one who planned SFD submit a post about it? Did it get hung up in the approval process? It would be nice to know so that someone will know how to do this better next year. When I hope there's a post in time for me to actually attend.

Title pretty much sums up the plot. One of my favorite books when I'm in a really dark mood.

Before you do anything else, read Robert Austin's book, "Measuring and Managing Performance in Organizations".

The points I got from the book:
1) Measuring the wrong thing or in the wrong way makes things much, much worse.
2) Good measurements are possible but take a lot of hard work.
3) Measuring things that are easy to measure is almost certainly wrong.

I also endorse BenEnglishAtHome's comment timestamped 8:55pm.

My wife did that once with mustard powder when making deviled eggs. They came out ... a little on the warm side. So, we called them Szechuan Deviled Eggs, and now we do them that way all the time.

Did you watch Randy Pausch's Last Lecture? http://www.cmu.edu/randyslecture/

Would your wife be interested in doing something like this? I assume privately, but maybe she'd want to make it public.

Get a copy of Michael Feathers' book "Working Effectively with Legacy Code".

I taught a grad / undergrad course using this book. We took a real open-source program as the class project, and the teams made significant changes to it. I thought it worked well.

Pat

I've seen this happen with Siggraph. The contract that Siggraph had with the hotels said that no vendor suites would be allowed for display of products or meetings with actual or prospective customers without explicit written permission from Siggraph management. All vendor suites had to be booked through Siggraph.

In, I think 1994, several vendors had such suites and publicized them at the exhibition. Siggraph management charged the hotel the standard suite fee for each of those vendor suites. Collected it too. I don't know if the hotels managed to get it back from the vendors or not.

I was test manager on a 50-person project. The development manager and I noticed that we had managed to hire a bunch of people who couldn't code their way out of a loop. I guess this showed that we weren't good interviewers. What we did about it was to write some tests of our own and give them to candidates. I never had a person decline to take a test. We did find that our tests discriminated quite well between candidates, and we found that we ended up happier with people who did well at our tests even if they couldn't talk the talk well.

All of our tests were very straightforward, no surprises or curve balls. And since we were the ones who had written the tests, we knew the material well. Some of the questions, we knew there were very specific answers to. Others, we just asked, "Here's a thing. Say something interesting about it." We calibrated the tests by giving them to current employes. We revised them until the people who were doing good work did well on them and the people who were doing poor work did poorly on them.

The better candidates pointed out errors in the tests. The best guy was someone who obviously thought a lot like me. After 10 minutes, we both got so involved in solving a coding problem that we forgot we were in an interview. He was a great asset to the project, at least until he decided he wanted to work nights so he could have another job during the day.

Bottom line: there's no way I'd hire a programmer or tester without seeing them program or test. Or in the ideal case, both.

(We made sure that the content of the tests was not related to the content of our project, thus avoiding even the appearance of asking for free work, unlike the slimeball referred to above.)

Check out the College Park Aviation Museum, just north of DC. I took a friend who was a nut about that stuff, and he went wild. He kept saying, "I knew that happened, but I didn't realize it happened HERE!"

They also have a full-size mockup of the controls of a Wright Flyer hooked to a flight simulator program. After attempting that a few times, I thought it was a miracle that the first fatal accident didn't happen a whole lot earlier.*

http://www.collegeparkaviationmuseum.com/home.htm

OTOH, if you don't care about pre WWII airplane history, don't bother.

*OK, imagine this. You're sitting in the plane. Your air-speed indicator is a piece of string hanging from a spar in front of you. You've got two levers, one on each side of you. If you're sitting in the pilot's seat, moving the left-hand lever front or back moves the alerons, changing your angle of attack from up to down. Moving the right-hand lever controls the warp. Pushing forward rolls you right, and pulling back rolls you left. Or maybe I'm mis-remembering and it's all backwards from that.

Now imagine moving over to the co-pilot's seat. The levers are reversed: right is alerons, left is warp.

And the throttle is a switch. It's either on or off.

I thought it was a minor miracle that it only took me three or four attempts to keep it in the air for two whole minutes without crashing.

You're right; sorry. Try this one: http://www.itl.nist.gov/iad/894.05/docs/CDandDVDCareandHandlingGuide.pdf, looking at pages 21-22. Also see the notes about adhesive labels on page 23. They're also a no-no. Pat

I recently tried reading a bunch of audio CD-Rs burned between 2003 to 2007. I used Exact Audio Copy on a Toshiba drive. I was able to get error-free reads from about half the disks recorded in 2003; about 3/4 of the ones from 2004, and from all the ones recorded after that. On the early ones that worked, sometimes EAC took a couple of hours to do the reads, which means it was doing a lot of retries. On the later ones, the transfers were mostly just a few minutes. On the ones that reported less than 100%, sometimes EAC spent 50-60 hours trying.

For the disks that I could not get 100% reads on from the Toshiba drive, I tried them in several other computers using a variety of programs. Mostly I was not able to get results as good as EAC on the Toshiba drive. I tried two Mac Mini's using Max and an old Mac G3 using cdparanoia from the command line, and got lots of failures. Then I tried Max on my MacBook and they all read perfectly. Go figure.

I theorize that one reason the disks had errors was that they were labeled using a Sharpie. According to the NIST report on CD-R failures (nvl.nist.gov/pub/nistpubs/jres/109/5/j95sla.pdf), this is a really, really bad idea. Since I read that report, I've been adamant about using only water-based markers on CDs and DVDs.

See, for example, http://www.jstage.jst.go.jp/article/jea/14/Supplement_I/14_S18/_article for a study in Journal of Epidemiology showing what I wrote. There are more.

... showed a similar result, until they controlled for for that.

Teetotalers were on average somewhat more likely to die than people who had a few drinks each week. Sounds like the same thing. Until someone realized that there were two subgroups of teetotalers: lifetime teetotalers and former alcoholics. The former alcoholics had a history of drinking a lot, but currently drank nothing. When they split those two groups apart, the lifetime teetotalers were the healthiest group.

I'd bet that the same thing will eventually be found here. There are two subgroups within the normal weight group: those who have always been healthy as distinct from those who have 'normal' BMI because they have some other health problem that affected their weight

From my reading of the description, the system that Arizona has isn't all that much more insecure than the paper system they have. There are a very few more ways to attack it, but I think that to perpetrate a major attack, it would be easier to make the attack on the paper side. Given that, I think the electronic system is "secure enough", at least until they make the paper system more secure.