It's the mid-1990s, and this big corporation is working on a major development project to replace most of its critical systems, says a Unix admin pilot fish working there.
"A major contracting firm was hired to design the development environment and help with development," fish says. "The contractor recommended against purchasing a large Unix machine for development, and suggested purchasing numerous Unix workstations instead.
"By their account, each workstation could support four developers working simultaneously, and machines could be purchased as needed as more developers were brought on board. This would be the most efficient and cost-effective solution, according to them."
Fish strongly recommends against this approach. Instead, he pushes for a single huge multi-processor server to support software development. To the surprise of no one -- including fish -- the corporation goes with the outside recommendation.
A few months later, roughly 40 workstations have been purchased, configured and put into use. And every time new software needs to be installed or operating-system patches need to be deployed, fish and his co-workers have to go through the same drill.
They run to the server room, put CDs in the workstations a few at a time, run back upstairs to their desks to execute the install routines, then repeat the process for the rest of the 40 workstations.
"Managing these 40 machines took up more of our time than all other Unix machines company-wide," says fish. "Two additional Unix admins were hired to help with the workload, and in the end there were five Unix admins supporting the 40 development workstations, while two other Unix admins supported the other 50 machines, including all production servers and the legacy development environment."
That's not the worst of it. The workstation-based developers have 87 percent uptime, while everyone else is at 99.8 percent uptime.
In part, that's because if two or more developers on a single workstation try compiling code at the same time, the workstation bogs down and is unusable, so reboot requests are constant.
And because the corporation has decided to save money by purchasing just three floating licenses for the compiler -- shared among 120 workstation-based developers -- compile requests often queue up for hours waiting for a license to let them run.
"I left the company soon after, but heard the project was years late, and never fully implemented before technologies changed and the project was scrapped," fish says.
"So much for the 'most efficient and cost-effective solution.'"
Help keep Sharky efficient and cost effective by sending me your true tale of IT life at email@example.com. You can also comment on today's tale at Sharky's Google+ community, and read thousands of great old tales in the Sharkives.
Get Sharky's outtakes from the IT Theater of the Absurd delivered directly to your Inbox. Subscribe now to the Daily Shark Newsletter.