Like many industries, IT has its share of charlatans. These people think they know what they're talking about, or don't know what they're talking about and fake it. This is because the business isn't aware of what it takes to make software; like a hospital's reception clerk isn't aware of how surgery works. But if a surgeon emerged from the operation room, soaked in blood, cursing the failure of Mr. Fairfax's operation to reconnect his hoozlevalve to the beppobone, some eyebrows would be raised.

Not so in IT, though. What we do is still black magic. And when we fail spectacularly, we can cause stakeholders to be skeptical of any future IT work. Such is the case on a job that Bruce W. took recently.

Bruce had been warned that the owners of a mid-sized, family-owned salvage company were afraid of being burned again by IT work. Still, they needed the work done, so Bruce became their IT director and developer. He'd be maintaining a system that wasn't what the owners wanted, had gone over budget, and still had the contracting developer milking the project.

Expecting the worst, Bruce started the software up and began clicking around. He was able to work his way through the system without any confusion; the UI was easy to follow. Looking at the codebase, it was well commented and managed to work with the company's idiosyncracies. In fact, while he found a few little sections that could use improvement, he couldn't find any major flaws that would cause the company to dislike the application. Bruce asked a friend that had been with the company for 17 years why the owners were afraid of IT work. "Oh, it's all because of The Sharon System," he replied. "Their hatred of The Sharon System has polluted their opinion of IT in general."

The Sharon System had started in 1998 when someone at the company discovered their custom written point of sale system wouldn't survive the Y2K rollover. Someone in the family found a developer that promised to put together a new inventory management and point of sale system. This developer managed to sell them on the system based on a background of government work, and the promise of free barcoding. Whatever that means.

Sharon spent nearly a year working and was excited to show off the system she had created. The company was excited to see it, too, and had two internal IT people run through the application so that they could train the cashiers how to use it. Well, they started it up and it crashed. After several hours on the phone with Sharon, crashing, tweaking registry values, and setting file permissions, they managed to get the software to start up. Still, it wouldn't be long before the software would crash again. The whole ordeal was so stressful that one of the two IT guys trying to run the application went home early that day, and came back the next day requesting to leave the IT group.

Once the other IT guy managed to get it running (more or less), he decided to take a peek under the covers. In the codebase he found that very little in the software actually did anything, the input screens had mislabeled input boxes and were very hard to follow, and the entire system had been built with Access's macro generator.

He called Sharon and detailed the first pass of what had to be fixed — everything. Still, he tried to politely point out that it's probably not a great idea to use the Access macro generator for everything.

After months of back-and-forth, a relatively workable system was hobbling along. The Sharon System 1.5 included features such as:

  • SMALLINTs used as primary keys for tables that should hold tens of thousands of rows — noticed when the application locked on a table that had a key value of 32,767.
  • Tables featuring multiple implementations of similar key fields — because sometimes you need a long integer, sometimes a string, and sometimes a string with leading zeros!
  • Each register gets its own database — sure, most businesses have one database server. But why do that when each client can have its own database and not tie up network resources? Of course, pricing data, transactions, etc., are inconsistent from register to register, but that'll be fixed in TSS 1.6 maybe!
  • You can close sales on a register once a day — closing the register for the day writes a file to the network with sales records. If you reopen and close the register again that day, the file's overwritten. This feature saves hard drive space, removing pesky transaction data that other point of sales systems would record and archive.
  • The database automatically stays below 1GB in size! — because a process was built to clean it out once a month. The application would crash if the database went over 1GB.
  • It's moving to SQL Server! — forget all the great Access features I just mentioned; the application will soon be running on a SQL Server database. Of course, Sharon took the liberty of restricting the database size to 500MB, even though a "cleaned" database is over 600MB.
  • Sharon's on it! — don't worry if there's a broken feature. She'll always make time for a reassuring "Oh, I forgot about that!"

Work on TSS 1.6 was sadly never completed. During a meeting to review the company's options, someone summed up the option of revising The Sharon System with "you can't polish a turd."

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