Thanks to a generous anonymous donation, Hudson High (as we'll call it) was finally able to trebuchet themselves into the 21st century. In addition to buying new computers for the teachers and staff, they found a contractor that would build them the ultimate system to maintain every function in the school, top to bottom. After a few months the system was built and deployed.

As one of the school's sysadmins, part of Jason L.'s job was to support the software. And it didn't take long for his eagerness to learn the software to turn into confusion, and it didn't take long after that for his confusion to turn into horror.

 

The GUI

They say you only get once chance to make a first impression, and this software totally blew its first impression (and every subsequent impression thereafter). The GUI... oh god, the GUI... It had one consistent feature across all windows — two (apparently randomly selected) retina-burningly bright colors applied as a gradient background. The top of the window would be, perhaps, the color yellow that you can only see by staring directly at the sun, and it would fade gradually into the color red that you could only see if your eyes were literally on fire.

The developer must have realized that these backgrounds would be pretty distracting, and that the welder's mask required to view the application made it hard to see the buttons. So the buttons were assigned even brighter colors, and to make them stand out even further, they'd blink. Each screen in the app had two to seven flashing, often unlabeled buttons with no tooltips (helpfully arranged in ROY G BIV order). If you wanted to know what a button does, hopefully you're friends with the original developer and can ask him.

Not unlike the basic survival skills everyone should know before entering the wilderness, Jason learned some common techniques to avoid breaking the software. The first rule he learned was if you see a flashing red button, do NOT click it. Without confirmation or any way to cancel, it clears the production database and starts you from scratch. Fortunately, it would only display for administrators.

The software suite was divided into several smaller components: (as we'll call them) InterLunch, InterPunish, InterPresence, and InterGrades.

InterLunch

InterLunch allows students to order their lunches, so long as what they wanted to eat conformed to InterLunch's standards. Would you like, say, a slice of pizza, some chips, and a soft drink? Tough — you can only order some quantity of one item. That is, you can buy a hundred slices of pizza if you want, but you have to decide whether you're going to eat or drink. And it was built to support only eight food items.

Since eight slots weren't enough to support the 70+ possible combinations of food items up for sale, the school went back to their old pen-and-paper system.

InterPunish

Intended to completely automate the school's discipline system, InterPunish had a host of features. "It even has a Detention Wizard," the programmer once boasted. The school even updated their disciplinary policies — each offense netted increasing punishments, starting with detentions, then in-school suspensions, expulsions, and finally being forced to stare at the InterPunish UI for a few seconds.

Ultimately, InterPunish didn't work out for the school since they required students to sign demerits, and there was no way to record this in InterPunish. Using it would've taken more time and energy than sticking with the old pen-and-paper system, so it was abandoned.

InterPresence

InterPresence was built to replace the pen-and-paper attendance system. Problem was that it only had two possible states: Present, and (unexcusedly) Absent. Even with doctor's notes and parental or faculty approval, excused absences were counted against the students.

Eventually they reached a compromise — InterPresence would be used only for Present and unexcused Absences, and for excused absences they'd be marked Present and have the absence recorded on paper. And after a little while, they completely reverted back to a paper-based system, leaving InterPresence with InterLunch and InterPunish.

InterGrades

This was the key part of the system — the other software was all well and good, but InterGrades was what really mattered. The goal was to have a single point of entry for all grades for all students, making it easy to pull class averages or drill down to a specific student and see how they were doing.

And it was about as successful as the other products in the suite.

Its first problem was with math. If I was to ask you what a student's grade was if she got 95% on everything she'd done, what would you say? Probably 95%. And you'd be right, using Earth math. But if you use InterGrades's proprietary math, you'd realize that the student was actually failing with a grade in the low 30s. When this was discovered, the school board decreed that all grades be recorded in the old pen-and-paper gradebooks.

The Backend

These applications were built on an Access database, and the quirks of dealing with the database first appeared during installation. Specifically, the database path was case-sensitive, despite it being a Windows application. It also had to be in the first subfolder of a root folder on a network share, no exceptions. And the subfolder has to start with a dollar sign. And much like confirming your email address or password, the installer required that you enter the same path twice for verification.

Updates are handled like so:

  1. User clicks an irritating blinky button
  2. InterWhatever downloads the entire database onto the user's computer
  3. User makes changes
  4. Wait for the database to be available with no other users editing and download again
  5. Merge the user's changes back in
  6. If the database was changed while attempting this, go back to step four
  7. Upload the modified database

This made things get real interesting at the end of the semester. With thirty teachers and a 100MB database, (300MB per request), it didn't take long for the network to go down.

Going Dark

Each product in the suite had one thing in common with all of the other products in the suite — the seizure-inducing UI and being completely useless. The developer genuinely wanted a happy client, however, and promised free data updates and support for (the rest of his) life if the school promised to test it in a production environment. And shortly after making that promise, he disappeared. It was total radio silence; ignored emails, unreturned pages, unanswered calls. Not only that, but he doesn't even live at the same place anymore.

The school tried and tried to make the most out of the software, but every product was completely useless to them. After blowing over $10,000 on the project just to go back to pen-and-paper, the board decided to do a gradual rollout of a commercially-developed web-based suite. And although the new software is working great, it doesn't have the neon gradient/blinky button UI they'd grown accustomed to.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!