Dr. K’s Software Ruminations

Computer Glitch Leads to Brawl at Wauwatosa Kmart

If this were fiction, I would pan it as being ridiculous and unbelievable. Alas, it is true…

A melee at a Kmart store in Wauwatosa [Wisconsin] Saturday morning was started by a computer glitch.

The store was running a promotion in which it would give away $10 to anyone applying for its credit card, but the computer glitch led to everyone’s application being granted — bestowing up to $4,000 in instant credit to anyone who applied even if they shouldn’t have qualified.

Once word started to spread about the so-called “free money” Saturday, witnesses said things got pretty nuts inside the Wauwatosa store.

Nearly a dozen Wauwatosa squad cars responded to the call just before 11 a.m. Saturday for what was called a large fight in progress.

“It was a nice brawl. It came from inside to outside. If you go up there, you’ll see hair, earrings, all pulled out on the ground,” Wilson said.

What started as a fight between two women in the crowded store evolved when several men intervened.

A store employee got punched in the nose and crashed through a glass display case. He was treated for a broken nose and various cuts.

Let’s be clear about a couple of things. The credit application problem was almost certainly caused by a software bug of some kind (a bit more accurate than the imprecise and somewhat generic “computer glitch”). But the fracas was caused by the mob mentality of a group of people lacking both personal moral control and common sense.

To paraphrase a favorite mantra of the NRA, “Computer glitches don’t throw people through display cases — people do.”

My most recent post to the PPIG mailing list…

On Jul 4, 2007, at 10:55 AM, Frank Wales wrote:

Charles Knutson wrote:
I believe there is a taxonomy of four types of people, relative to
professional software construction:
1) Those born to code, who need almost no coaching;
2) Those born capable but in need of training in order to be successful;
3) Those not really born to it, but who can be trained sufficiently to make a living;
4) Those whose brains are really not wired to build software at all.

As a matter of interest, do you have a sense of how the general population
is distributed across these suggested types?

Rather than just categories or types, I’d actually propose a spectrum
of capabilities, with people who just ‘get’ computer technology at one
end, people who would sooner eat lint that use it to check their C
programs at the other, and the substantial mass of people bulging
somewhere along the middle. (Of the spectrum.)

I’d speculate, completely without anything beyond years of experience
and arrogant presumption, that the “just get computer technology” end
of the spectrum glows with about 5% of the population, the “couldn’t
write ‘hello, world!’ despite years of practice” end is dimmed by maybe
15% of the population, while the remaining 80% of the population huddles
around various quantumly-distributed embers in between.

I think the end groups are inherent, while the huddles are plastic.

Of course I have no objective evidence for what the actual distribution might be. If anyone has seen any empirical take on this distribution, it would be very interesting. I could easily buy the idea that the top is 5% and the bottom 15%. I also concur completely with the idea of a spectrum. My taxonomy was more of a highly granular way of describing such a spectrum. My apologies to anyone who was expecting a fist fight

Two last thoughts on inherent aptitude:

1) I’ve recently run into students who took the first semester programming class at BYU, did well, got their ‘A’, and then washed their hands of the field and went off to study business or something else. Clearly they are capable of programming, at least at the entry level, but the biggest dissuading factor to them was the inherent motivation (or lack thereof). One of them told me that after spending 15 hours on a programming project, and finally getting it working and passed off, they felt like they had been robbed of 15 hours of their life that they would never get back! That was such a news flash to me! In *my* experience, every program or project I ever finished has carried with it some sense of euphoria and satisfaction that seemed to make all the pain worthwhile. And much of my programming time has been somewhat rhapsodic, like a runner’s high. So while I don’t consider myself to be the most gifted programmer (or even necessarily a member of the first group) I have always been quite satisfied and happy with the process of constructing software.

2) I just started reading Stephen King’s “On Writing.” Interesting to find this quote on page 4 (substitute “computer programmers” for “writers”):

“This is not an autobiography. It is, rather, a kind of curriculum vitae — my attempt to show how one writer was formed. Not how one writer was *made*; I don’t believe writers *can* be made, either by circumstances or self-will (although I did believe those things once). The equipment comes with the original package. Yet it is by no means unusual equipment; I believe large numbers of people have at least some talent as writers and storytellers, and that those talents can be strengthened and sharpened. If I didn’t believe that, writing a book like this would be a waste of time.”

Just a bit more grist for the mill.
Chuck

The following is an email I just posted to the PPIG mailing list, in response to the following comment:

For the record, I believe anyone can learn to program at a professional level. The question is, are they willing to put in the time to acquire all the chunks needed to be an expert? Unfortunately, we can’t force our students to put in the time.

I’m not convinced that absolutely *anyone* can learn to be a professional X (whatever X is). I think there are some who are really just wired to do other things. But I am confident that there are varying degrees to which inherent aptitude plays a role, and similarly varying degrees to which effective learning experiences contribute to facilitate those individuals who can, in fact, be successful at profession X.

As evidence, I offer the following non-empirical anecdote. I started programming in 1973, when I was 13 years old. Our high school had a timesharing account on a mainframe at the University of Northern Iowa, and a DecWriter with a suction cup modem and a rotary phone with a dedicated line to the university. About a half dozen of us math geeks gathered daily in a room to play with the computer (which largely consisted of playing Dungeons and Dragons and Star Trek, with intermittent fits of attempted software design and code construction). Several of my friends just seemed to have the knack right out of the chute. We’d dumpster dive at the university for discarded manuals, and that was all Brian and Doug needed to build software. I tried desperately but couldn’t get it beyond a fundamental level. The other guys were more or less like me, in love with the technology, but not fluent with the incantations.

Years later, in my second semester at the University of Iowa, I had a really well constructed and well presented Computer Science class that focused primarily on design. During that semester, the light came on, and I got it! From that semester it was simply a matter of learning new skills and piling them onto the foundation I had now acquired. I had a very successful professional career building software (HP, Novell, various small companies and consulting gigs), picked a few graduate degrees along the way, and then retired to the university to stop producing and begin pontificating.

As an epilogue, of the group of math geeks that gathered together daily in high school to play with the DecWriter, all but one of us acquired degrees in Computer Science, with the other one (Brian) doing Electrical Engineering.

My personal experience is that I was always fascinated, I was obviously capable, but I needed someone to throw the switch for me to understand how to become self-sustaining after that.

I believe there is a taxonomy of four types of people, relative to professional software construction: 1) Those born to code, who need almost no coaching; 2) Those born capable but in need of training in order to be successful; 3) Those not really born to it, but who can be trained sufficiently to make a living; 4) Those whose brains are really not wired to build software at all.

Just my two cents. Your mileage may vary.
Chuck

IT doesn’t matter

That’s “IT” as in “Information Technology”… doesn’t matter. This article by Nicholas Carr first appeared in the Harvard Business Review in May 2003. He reprinted it here on his blog Rough Type in January of 2007. It’s fairly lengthy (8 parts) but worth the investment.

Here’s one of his key punchlines: the commoditization of IT…

“Behind the change in thinking lies a simple assumption: that as IT’s potency and ubiquity have increased, so too has its strategic value. It’s a reasonable assumption, even an intuitive one. But it’s mistaken. What makes a resource truly strategic -– what gives it the capacity to be the basis for a sustained competitive advantage –- is not ubiquity but scarcity. You only gain an edge over rivals by having or doing something that they can’t have or do. By now, the core functions of IT –- data storage, data processing, and data transport –- have become available and affordable to all. Their very power and presence have begun to transform them from potentially strategic resources into commodity factors of production. They are becoming costs of doing business that must be paid by all but provide distinction to none.”

It’s an extremely well-written article, and very thought-provoking. I’ve been thinking a great deal lately about enrollments in Computer Science programs around the world, and wondering what role this sort of commoditization of information services plays in all of that. Obviously it may have a greater impact on programs like Information Systems or Information Technology, but all of these academic programs seem to be rising and falling together to some extent.