michael created the topic: Building the Weird Stuff
You may ask yourself, what is the "weird stuff" statement all about? The weird stuff is unusual requests, mind-bending projects and tasks that fly in from so far out in left field that you never had any idea that someone might want such a thing done - they are unconventional projects to solve unconventional problems.
Possibly the most interesting aspect of these "weird" projects is that someone "knows a guy" who could fix it; they were all obtained through word-of-mouth. RicheyWeb has never spent a single dollar on advertising.
And now you also know someone who tackles weird projects.
Only 20 tapes at a time
A data recovery project on the East coast got weird early when the client requirements allowed only 20x 200GB SDLT2 backup tapes to be released at a time, and the tapes were to be no more than 15 miles from the storage facility. Making things tougher, they had no idea what the backup method was.
Fortunately, they sent a single tape to Texas for examination and we were able to forensically analyse the backup method and come up with a plan, which made us comfortable enough to submit a proposal and accept the job. Taking on this kind of job required more hardware than we kept on hand, so some purchases were made, a van was rented and the journey East began.
What makes that weird? The forensic analysis of the tape revealed that the tapes were network backups of several servers in an AD domain. In order to restore the tapes, the network and AD structure needed to be present to receive the restored data. All of the software to accomplish automation of that task was written on an laptop from the passengers seat of a rental van full of computers and robotic tape changers while driving from Dallas Texas to Boston Massachusetts - and it worked perfectly upon arrival.
So many frustrated users
A wireless ISP in Texas had a big problem - bandwidth management. Their customers were eating them alive, and the configuration for bandwidth management on their client devices was so complex that only 2 employees knew how to do it and it took 5 minutes to accomplish on each device. Non-pay disconnects would take days to finish, and reconnects would take just as long - making for frustrated customers and employees.
After some investigation into the network devices, a system was put in place to provide a query mechanism for the client devices to provision their own bandwidth management. This system interfaced the client database with the accounting database. Software was written for the devices (in Lua) to periodically retrieve account status from the CO. Any change in accounting status (past due/paid in full) or change in the client service level (bandwidth upgrade/downgrade) would trigger an internal re-configuration of the devices bandwidth management. Any employee could then make a change that would be made effective within minutes - no frustration required.
All you need is COBOL
A computer manufacturers call center in California had a reporting problem and an IT deficiency. After months of trying, the IT department couldn't process the amount of data generated by their phone switch in a manner that lent itself to the generation of the daily reports required by the call center managers. The departmental separation between IT managers and call center managers meant that nobody was really being held accountable. The only recourse the call center managers had was to assign 2 phone workers to the generation of the daily reports. That was 2 man-days to process 24 hours of phone switch records which were then delivered 48 hours after the data was collected.
Investigating a solution to this problem, a single onsite system was found to have a capable data processing language - but that language was COBOL - the programming language invented by Grace Hopper in 1959 - that COBOL. This was a call center after all, and they didn't do much data processing outside of a spreadsheet now and then.
After planning the process, an application was written to retrieve and process the phone switch data every 15 minutes, generating a report that was not only timely - but could also yield information helpful to the call center volume today, where it's impossible to be proactive using a report about what happened two days ago. On top of that, 2 employees were once again productive on the phones. Paying the equivalent of 80 man-hours once saved them 4,096 man-hours annually, and 5,000% annual is one heck of an ROI.
Roll the trucks...or not
A residential security company in Dallas Texas made a mistake - a very big mistake. When programming security systems prior to installation a key feature was left disabled, meaning that thousands of alarm systems had a critical security vulnerability. The company began planning to send technicians to each and every installed system for re-programming, making the error painfully visible to their customers.
Upon receiving the request to review this problem, all documentation for the security systems were evaluated and it was discovered that there was a way to trigger the system into initiating a remote programming session. This little known feature turned into a solution that saved time, fuel and reputation. An automated process was built to retrieve the current configuration, make modifications and push those new configs to the system - and the entire process took only a minute or so per system.
Once completed, several thousand systems had been re-programmed and technicians only needed to visit a precious few customer locations. The rest of the clients were informed after the repairs had already been made - instilling confidence instead of angst. This phrase seems appropriate - "Snatching victory from the jaws of defeat."