Back in the early 1990's, G.R.G. worked at a certain university as a programmer. In addition to breaking into server rooms and deafening cute little chinchillas, G.R.G. built one of the university's first web applications. It was a fairly simple CGI program that provided web-access to the student registration known as Old Yeller.

Even in those days, the university’s student registration system was considered to be ancient. Running on an System/370 that had long since seen its day, Old Yeller was based off of an off-the-shelf system and customized over the years with various COBOL and Assembler patches. Though it wasn't too pretty, Old Yeller reliably handled 85,000 registrations each semester and brought in about $400 Million a year. And all in less than a megabyte of RAM.

When the new-fangled World Wide Web came around, G.R.G. saw an excellent opportunity to modernize the registration department’s operations, help decrease the long lines each semester, and, most importantly, work on a fun, new project. Along with his coworker and manager, G.R.G. proposed that they build a CGI interface to Old Yeller that students and faculty could use. They estimated that it’d cost a few thousand dollars in hardware and software, and a few hundred hours to develop.

Though G.R.G. wasn’t part of the official Application Development Unit, the price was right. The registration department approved the project and G.R.G. and his coworker got started on it right away.

A New Face for Old Yeller
After several long weeks of coding in their dark, windowless office – originally a coat room – they had finally completed a web frontend to Old Yeller. It was very basic and provided students with two simple options: add a course using the cryptic COURSE_ID from the printed catalog, or a drop a course using the even more cryptic COURSE_REGISTRATION_ID from the registration confirmation printout. And it all ran on a measly 66-MHz 486 PC. But it was enough.

Students from the pilot group were more than happy to go to the deserted computer lab and punch in their course numbers instead of having to wait in line for hours. The registration folks liked it too, as it meant that much less work. The next semester, the web frontend got a few more features and was opened up to more students. The semester after that, more features were added and all students could use it. And all the while, the CGI ran smoothly on their dinky old 486.

A few years later, the official Application Development Unit finally caught wind of the Old Yeller interface. “It’s pretty cute,” one of the ADU managers said, “but I think it’s time we build a real self-service interface. And this time, let’s build it right.”

Building it Right
Over the following months, the university’s CTO and some other big cheeses worked hard on the Student Registration System Self-Service Interface Pre-Analysis project. Several times a month, they’d fly out to different universities across the world and wine & dine their technology executives in order to get some good inside information on self-service interfaces to student registration systems.

After nine months, the Pre-Analysis was complete. They determined that, in order to build the self-service system right, they’d need a budget of four million dollars and need the assistance of a team of consultants from a certain three-lettered firm. And since that’s what it would take, the trustees signed off and development of “Mother” – the project’s code name – began.

The kick-off meeting for Mother was held at XXX Corp’s offices in Watchagotchie, Canada. Several managers and developers from the university’s ADU flew out to meet the project managers and the forty consultant developers. They all worked in gleaming offices ensconced in tallest tower in Watchagotchie, and discussed how they planned to write the web-interface using the latest tools, in the latest programming languages, with the latest testing tools, and utilizing the latest project techniques.

Everyone was excited: together with XXX Corp, the university would build the greatest self-service interface ever.

Leaves fell, seasons changed, elections passed, and “Mother” was finally delivered. It was powered by a massive $800,000 mainframe with thirty-two CPUs, water cooling, and 256MB of very hot RAM, all which were housed in the university’s new, raised-floor data center. G.R.G.’s CGI – with its 66Mhz PC and 20Mhz backup PC in a broom closet – went from being “cute” to downright pathetic.

Mother Comes To Life
Every new system has its glitches, and Mother was no different. When the registration department opened up Mother to the students, they noticed that, after a few hours of use, the entire system would crash and need to be restarted. Developers at XXX Corp claimed that this was impossible, as they had thoroughly load-tested Mother, but eventually agreed to investigate their testing code.

As it turned out, one of the developers in the gleaming tower coded a small bug in the core of their advanced load testing tools. Though the tool reported that thousands of users could easily use the system simultaneously, the tool inadvertently ran user simulations in serial, not in parallel. When they fixed the tool to run simultaneous user simulations, Mother would crash within seconds.

Developers in the university’s ADU worked frantically with the developers in Watchagotchie to get it working. They were eventually able to massage Mother into handling, slowly and buggily, a small number of users.

With few other options, the registration department posted notices throughout campus asking students to only use the system on “their” day (A-M on even numbered days, N-Z on odd) and that they try to spread the load around the clock. Even so, the load at 3AM was more than Mother could handle and only a lucky few managed to register for their classes.

All the while, GRG’s old interface to Old Yeller was quietly kept online, and word quickly spread that one could actually register on it and not get a Java stack dump as Mother was prone to do. The university’s ADU was adamant that Mother would soon be fixed, and that GRG’s CGI would soon have to be taken down.

With only two weeks of registration left, someone figured out a workaround to get Mother running. Since Mother had a problem with more than a few simultaneous users, they decided to run as many instances of Mother as possible. ADU developers gathered up hundreds of retired PCs, installed Mother on each of them, and wrote a program to randomly redirect users until a Mother with less than five users was found.

That did the trick. Mother was finally able to run, though still somewhat slow and buggily, but actually handle the load. It only took 4,000 times as much hardware as GRG’s CGI.

In the end, the trustees were happy that a self-service interface was successfuly built, and rewarded the folks in ADU with big bonuses and new offices with real windows. They even sponsored a project to investigate finally replacing Old Yeller. As for GRG and his fellow programmer, they stayed in their small coat-room office and got a 2.3% raise at the end of that year.

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