OmegaMom

The scientific method, that is.  Theories?  We don’t need no steenkin’ theories, man!  Hypotheses?  Pish-tush!  Soooo 20th century!  Experimentation?  Observation?  Oh, puh-leeze!  Who needs that stuff?  ‘Cause we’ve got data.

Gigabytes of data.  Terrabytes of data.  Petabytes.  Hexadeca-bytes.  Google-bytes, even!  (But not Google™ type bytes.)  Infini-bytes!  We have data pouring out our ears these days, thanks to the Intertubes, and so Wired Magazine has declared The End Of The Scientific Method.

‘Cause, y’see, we can take all that data, put it in a big Magic Data Mangler, shake it, stir it, decant it, and ta-da!  New science!  All these nifty correlations will spill out, neat science-y goodness just spread in front of us like a field of diamonds, sparkling and glittering and making us gasp at the magic of it all.  Kozmik All knows it’s much easier to do that than to, say, oh…think.  Who needs to look at the world and wonder "why?" or "how?" or "what would happen if we did x?"

I’m sure OmegaBro will be glad to know he doesn’t need to go traipsing off to all his field sites any more.  Why bother to investigate what happens to sawfly galls on southwestern stream willows in flood years versus in dry years?  Why spend your time counting galls on specific trees at specific sites each year?  I’m sure that information is out there in the interwebs cloud, just floating around, waiting for dear OmegaBro to write the proper program to collect it, stir, shake, and spill, and voila, he will have his community ecology interactions down to a "T".

Of course, there’s that silly little thing like, oh, deciding what to mine from the vast cloud of info out there.  And why.

As someone commented on the essay, "garbage in, garbage out"–that grand old saying about computers and data–applies here.  Given how infested the web is with spam and commercialism and outright crankery, using the "just grab all the data out there and whirl it around in some big-ass computers" approach might deposit a lovely fewmet of, say, colonics cleansing being effective at removing years-old parasites from poor haggard human bodies.  Or someone might use it to prove that Indigo Children really are an increasing influence on world politics today.

Lots of other folks have said it, but I’ll say it, too:  Theory is not dead.  The scientific method is not passe.  The Wired essay is waving its hand at statistical correlation being science, all gee-gosh-golly-wow charts-n-graphs.  But that’s not science.  It’s cool, yes, I’ll grant that.  And lots of interesting information is coming out of the expanding ability to correlate disparate groups of data and seeing what patterns emerge.  But science is asking "why?", trying to figure out the natural world, trying to understand underlying laws that drive the universe, delving into genetics and fossils and tokamaks and outer space and multi-dimensional math and gravity and thermonuclear processes that make stars burn bright…

All that kind of stuff.

Y’see, the information mining that Wired is going gaga over has–as its very basis–human beings who explored the world and teased out important basics based on theories, based on thousands of years of human beings asking questions, posing hypotheses, testing them out, deciding what works and what doesn’t, and why it works that way and not another, and how to harness the way it works to make life easier (or more complex) for humanity.  And it requires humans asking "why?" and wanting to know the answer to even decide to make the Magic Data Manglers look at one particular set of data in particular, before the MDM spills out its oh-so-pretty correlations.

So I have to say, the scientific method–theory, hypotheses, testing, experimentation, revision–is not dead yet; it’s not the red-shirted Away-Team member who always bites the dust in any Star Trek episode.

(No, not about taxes!)

Most of the time, I go through life thinking most people are pretty nice, that everyone (generally) just wants to get along, that the folks who get a kick out of hurting other people are few and far between.  That hackers are only interested in scoring, via macho skillz, or making money by scamming or thievery, but not interested in hurting other people.

Then I read something like this.

Hackers and spammers and what-not are branching out, it seems.  Not content with stealing people’s credit card numbers or identification, or posting 279 spam comments on an obscure blog per day for a week, they’ve now decided to target epilepsy patients, with something that hurts them.

An epilepsy support board was hacked by folks who put javascript in place to either display a seizure-inducing picture or redirect the post-reader to another website entirely that displayed a full-screen video of seizure-inducing patterns.

What kind of sick fucks would do something like that?!

I mean, really.  I can get "revenge".  I can get "personal animosity" aimed at one person.  I can get graffiti.  I can get theft.  But I can’t get the kind of personality that impersonally poisons an online medical support group with something that can actually physically incapacitate or hurt someone.  My considered opinion:  These are scum-sucking slimeball pigs with the morals of a hyena, like roaches of the internet, who should be squashed like the bugs they are.

Bastards.

Well, actually, yes we do.

A few weeks ago, I wrote about my little mystery hunt trying to figure out why the vehicle reservation system in my department of Small Mountain University was on the fritz, how I discovered that the unique identifier for each reservation was limited to four digits by Nice Young Intern, and how sometime in the past few months, we had hit 9,999 and the reservation numbers started all over again at 1, causing all sorts of funky errors.

My readers in the biz were appalled.  "Where was the code review?!" they proclaimed.

Yah, well.  (OmegaMom looks aside, shuffles her feet, coughs a bit…)

I love working at SMU.  I really do.  I started in the ITS department, got chopped in the Great Layoffs, took a (much less remunerative) position as an administrative assistant while waiting for IT jobs to re-appear, and then got my position in Current Department when the job market started warming up again.  The atmosphere on campus is collegial.  There are lots of cool folk doing lots of cool things on the academic side; there are lots of cool folk doing lots of cool things on the ITS side; there are lots of cool folk doing less cool but immensely important things on the business side, and almost everyone I’ve worked with at SMU has been intelligent, interesting, fun, and good to work with.  (I can think of two exceptions over the past nine years, that’s all.)

Anyway, in the ITS department, since we have lots of folks there, many ITS things were (and are) done by the book.  Good coders, good reviewers, good interactions between everyone.  But there are only so many ITS folk to go around, and those that are tasked with helping on more complex projects outside ITS are booked solid for a year in advance.

Out in the departments, there are IT folk who are hired as departmental support.  Itty bitty departments have to make do with no-one, or sharing someone with a few other itty-bitty departments.  Bigger departments get one or two.  Really big departments get their own geek squad.

Each of those support folk have to handle a wide variety of different issues.  There’s day-to-day support:  Figuring out why JoAnne’s email suddenly disappeared.  Helping Dr. Professor Jones stitch together a master document and sub-documents in Word (and trying to explain that master- and sub-documents in Word have a really bad reputation for getting corrupted and frying your entire 417 page manuscript).  Updating web pages.  Maintaining small databases.  Developing interfaces to bigger university systems, or maintaining old interfaces that have been just chuggin’ along for many years but need a tweak or two now and then.  Arranging repair for old equipment.  Buying new equipment.  Figuring out equipment budgets for the upcoming year.  Buying color toner when something needs to be printed in color RIGHT NOW!  Crunching numbers in spreadsheets.  Putting together pamphlets or brochures or quarterly newsletters.  Getting new people set up on systems and into the university system.  Running local servers.  Maybe running computer labs for students and staff.  Providing down-and-dirty training.

Rarely a dull moment.  Always fun to help people.  Good to get to know folks in all aspects of the higher education biz.

It’s sort of like juggling.  There’s always something that is urgent.  Typically, the urgent stuff is related to ensuring that everyone in the department is able to do their work.  Then there are the bigger departmental projects…which get done in and around the "making sure everyone can do their work" everyday stuff.  You’re catching the errors on this database while crunching the numbers for that report to the board while uploading PDFs to the website while figuring out why the network has gone down for the people in room 219 while…

What ends up happening is that whoever gets handed the bigger project just bulls in and does it. 

Like the project Nice Young Intern worked on.

It gets done, it gets tossed up, people who are chomping at the bit to get to use the project start working on it (ostensibly as testing) and then suddenly it segues into being used.  And rare is the chance to get someone to give your code a review.

I’m pretty sure Johnny and SpaceMom are shivering in their boots at that mild paragraph.  Where’s the project outline?!  Where are the specs?!  Where’s the test plan?!  Where’s the code review?!  Where’s the iterative process?!

I know, I know.  At times it bothers me, too.  But y’know what?  It’s really fun work.  You get to be a jack (or jill) of all trades.  You get to help people.  And all of these "bigger" projects are really, in the course of things, small potatoes; they’re "big" in relationship to the day-to-day stuff at the departmental level.  It’s not like the small army of coders and testers and code librarians and project managers handling a Truly Important Project like the online education program or the accounting program or the human resources program.  Those projects are vital, necessary to the lifeblood of the university as a whole.  They’re handled by ITS, they’re treated like good software projects should be, they take time and money and people and organization.  Those projects get code reviews out the wazoo.  Smaller projects that ITS takes on, handled by one team or another, also get the software project treatment.  But projects handed out to departmental support folk?  Those get dropped on the desk as a "Y’know, it would be nice if we could do x, y, or z.  D’you think you can pull something together in two weeks?" 

NYI’s project started that way, and my predecessor knew that it would probably not get done in any decent amount of time unless she borrowed a student from the CS or CIS programs.  It made a good summer project for NYI, and he did think it through, provide specs, program it, and get it up and running.  Since he specified only four digits for the reservation number, I’m thinking that people talked it over and figured that the program would be replaced long before they needed to worry about it.  Sort of like Y2K.

But code review?  What a luxury that would be!

When we moved, we lost our cordless phones.  (No, we’re not on wireless.  We couldn’t receive wireless at our old house, so it wasn’t worth the price.)  (Though I suppose we might be able to receive wireless where we are now.  Hmmm.)  Anyway, we purchased a (lousy, crappy, useless) dirt-cheap corded phone from the grocery store to tide us over for a while when we first moved in.

Then the tabby doohickey that sticks out to ensure that the phone actually, say, hangs up when you put the receiver down broke off.  When it broke off, I we had no earthly idea what it was for, so I we threw it in the garbage can.

Thereafter the (lousy, crappy, useless) corded phone was iffy, at best, about when you had really, truly hung up.  And if you weren’t in the vicinity to hear the beep beep beep noise that the phone company so carefully provides you to alert you to the fact that your phone is off the hook, after a while the beep beep beep would turn off and the phone line would go dead.  Thus, when folks, say, called you up–what a concept!–all they got was a busy signal.  Or, after we got our new phone service, a voice mail box.  We on the other hand would go merrily on our day to day lives, not realizing that (a) our phone was actually off the hook, and (b) other people were actually trying to contact us and leaving phone messages…until one or the other of us picked the phone up to make a call.

Since we’re not wild and crazy social guys, that would happen every few days or so.

Then we bought a cordless phone set.

Woohoo!  Entering into the modern age, we thought!

Then a few weeks later, OmegaDad, while reaching for something in the old iteration of the office (read:  cramped, messy, filled with poorly balanced heaps) knocked the main base off the desk.

::  All your base are belong to us!  :: some kozmik kritter proclaimed.

Our base no longer worked.

Our two related cordless phones no longer worked.

One of our corded phones didn’t work.  This particular clue makes me think, in retrospect, that it was not OmegaDad knocking over the base unit that did it, but that some Evil Coincidental Voltage Spike did it instead.

Only our (lousy, crappy, useless) corded phone that was schizophrenic about whether it was actually hung up or not (thus having a hang up on hang-ups, eh?) was "working", in the sense that we could place calls and receive calls–when it was hung up.

So OmegaDad finally purchased new cordless phones this weekend.

We plugged them in and started charging those puppies up.

Last night he did all the proper registering and what-not of the phones.

Everything seemed hunky dory.  Maybe–just maybe!–this time our phone situation would last longer than a week or two!

This afternoon, OmegaDad, being a loving and sentimental fella, gave me a call.  In a graceful, swan-like dip, I reached over, grabbed the cordless phone, pressed the "talk" button, and started talking.

As I was talking, I noticed that the network had gone out on my computer.

"Hunh!" thought I.  While talking to OmegaDad, I started fiddling with various network things on the computer.  Nothing worked.  I announced to him that the network was down.  I hung up the phone, fiddled with some more networking things, and the network got back up, dusted itself off, and started working again.

I gave my computer the hairy eyeball.

That was mighty coincidental, I said to myself.

I picked up the cordless phone.

I dialed OmegaDad’s office number, watching the networking indicator on the computer.  Ring, ring.  Nothing happened.

Then OmegaDad picked up the phone.  A second later, the network went down.

I gave my computer the hairy eyeball once again.

"Dude.  When I talk to you on the new phones, it kills the wireless network."

OmegaDad thought it was the cabling (our phone lines are carried over the cable network).  I was sure it was telecommunications interference of one sort or another.  I hung up.  The network came back up.  I read the phone manual.  They made sure to tell you about other things interfering with the phone, but not a word about the phone interfering with other things.  Grrr.

I flexed my Googlemeistra fingers and typed in "wireless phone computer interference".  After reading a variety of things, it turns out that our (cheap!) cordless phones, which transmit on 2.4GHz, interfere mightily with various 802.11 wireless networking protocols, because they, too, are on that frequency. 

The OmegaFamily was very, very close to dumping the new phones.

Then I found something that talked about being able to assign a frequency to the wireless router.  Specifically, that while the majority of the bands used by the wireless router are overlapping channels, 1, 6, and 11 are unique and don’t overlap.  I logged into the router.  I fiddled with settings.  I found a way to select channel 11 (the one I remembered off the top of my head as being unique).  I saved.  I picked up the phone.  I dialed OmegaDad.  He picked up. 

And lo and behold, the network didn’t go down.

Let that be a lesson to you.  Googling rulz!

(I thought about titling this post "What’s the frequency, Kenneth?!"  Does this date me?)

(Technical stuff follows.  Feel free to ignore.)

Oooooo!

So there we are at work…our transportation center has an online reservation system that was written by a Nice Young Intern.  It was written back in 2002 and has worked okie doke since.  (Aside from the fact–which I discovered recently–that it has been running on the development server all this time, rather than the production server.  To those of my readers to whom that is an arcane distinction, let me just say:  production servers have paging systems.  If the production server goes down in the wee hours of the night, some poor ITS minion is paged and required to dash in to the office to Figure Out The Problem Right Now!  This does not happen with development servers.  If a development server goes down, the priority to get it going again is low on the totem pole.  Also, DBAs feel quite happy to Do Things to development servers, without worrying that they’re going to break something.)

Recently, we’ve been getting complaints from our TC that the users of the online reservation system have been getting errors.

I investigate.  Luckily (or not so much ‘luckily’ as ‘almost inevitably’, as it turns out), I immediately get an error page.

(Let’s set aside the fact that there’s no error checking, so we don’t have a “nice” error page telling our users that oops, there’s a problem, and please try again later??)

The error page says “unique constraint violated’.  What the heck?  Why would that happen?

Interestingly enough, the DBAs had just updated the development server shortly before the TC folks really pushed us about this error.  So I went down that path for a while.  But a DBA, when emailed, provided a clue–he said that we’re trying to insert new rows with a duplicate primary key.  (A ‘primary key’ is a number that uniquely identifies a row in the table.  For instance, if you’re doing a credit card transaction, the primary key might be, say, your transaction number.  No-one else is going to have that transaction number…or no-one else will have that transaction number on that date, so the primary key would be trans number plus date.)

I noodle around.

I investigate.

I discover, much to my absolute and utter horror…

The Nice Young Intern had set up the reservation numbers as the primary key.  This is okay.

The NYI had an automatic number generating doodad set up in the Oracle database to generate those reservation numbers.  This is okay.

The NYI had not used the default maximum limit for the reservation number–which would be some gawd-awful number like 999,999,999,999.

No.

The NYI created the reservation number system to have a maximum number of 9999.  This is not okay.

So…once the TC had gotten reservation number 9999, what happens?

The automatic numbering system starts all over again, at number 1.

Back when the system was being developed and tested, there were loads of jumps in the numbering system.  NYI would try a reservation, it wouldn’t work, he’d back out, that reservation number would be discarded…But as the system went online and real people started using it, the gaps in the numbering system would become fewer and fewer in number.

The first few hundred numbers worked okay.  Users would get an error once every great while, when the system tried to save a reservation that had a reservation number already used in the system.  But now…now…the gaps in the numbering system are few and far between.  Thus, as I said above, it was almost inevitable that the test reservation I made would not go through.

Why the fuck would someone create a system keyed on an automatic number that rolls over when it hits 9999?!  This is like our own little tiny version of the Y2K problem.

And I’m hopping mad about it.

Luckily, it’s an easy fix.

Grumble, grumble, grumble, bitch, moan, complain.