Ahh, print publications. Remember those? You'd go to the store, open a magazine, await the avalanche of cards that would fall out, fish one card out of the pile, fill it out, send it in, then camp out by the mailbox awaiting your first issue. Jim T participated in an internship on the IT staff for a popular magazine in Chicago. I know what you're thinking, but no, it's not a nature magazine, though bunnies are involved. Subtlety!

Anyhow, he was tasked with interfacing his magazine's site with a fulfillment house's site, allowing people to subscribe online. Everything was in place, so it couldn't be simpler.

See, all he had to do was make a link to the fullfillment house's site where the subscription form could be filled out, then redirect the user back to the magazine's site. "But wait," cried the powers that be, "we can't allow users to leave our site!" The magazine wanted to own all rights to the content and the ability to update it at will.

Fortunately, the fulfillment house had a CGI app that Jim could post form data to. It'd only make sense that an application like this would accept the data and a redirect url, then data would be passed back to the provided url. Parse the data, populate the page, and you're done. Easy.

But no, a single number was returned by the script. You then had to manually look up whether it worked or not. The developer that made the script was long gone and the fulfillment house was no help.

Jim was also concerned about transmitting payment data - specifically, credit card information. Sure, there's encryption, but honestly, who needs the hassle? The proposed solution? Hire a fleet of temps.

Yes, they proposed a solution similar to the "make a document in Office, set it on a table, take a picture, upload the picture, put it on a web site" approach. Specifically:

  1. Save data locally to the server.
  2. At the end of each week, print out all of the data.
  3. Fedex the data to the fulfillment office.
  4. Hire temps at the fulfillment office to rekey the data into their systems.

Several protruding-veined, blue-faced arguments later, IT was able to deploy an alternate solution, which sadly still sucked. Just not as bad.

  1. Data is still stored locally.
  2. The fulfillment house can grab the data via secure FTP.
  3. The fulfillment house would have someone manually run the file through a utility each week. This person would run it with their fingers crossed, hoping that all payment data was correct.

Since this was a weekly, manual process, the response time to the user was that of manually filling out an old-fashioned subscription card. The user would find out if payment was successful in six to eight weeks, depending on whether the first issue actually arrived.

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