The Daily WTF

Error'd: Upon Reaching a Certain Age...;

"Evidently, once you hit 55, LinkedIn thinks you'll age until your buffer overflows," writes Jonathan L.


"I started out looking for shower gel, but now, thanks to Google, I'm considering if a GBIC in Cadet Blue is worth the extra money," writes Robin M.


Matthew B. wrote, "So, an article about AI shows that the AI behind generating the summary rasied an exception. Maybe the AIs aren't speaking to each other?"


"Wait...did I just fail a Turing Test?" writes Daniel.


Rob J. wrote, "I got a 2 on a vision test but apparently only people from Krypton or blind people test on it, because there were very large negative and positive scores."


Pieter V. writes, "Thankfully this combo error didn't occur on the plane I took."


[Advertisement] Forget logs. Next time you're struggling to replicate error, crash and performance issues in your apps - Think Raygun! Installs in minutes. Learn more.

Classic WTF: Flawless Compilation;
Just today I was joking with my co-workers: I had written software for which we had no viable test hardware, but the code compiled, therefore I was done. The difference is I was joking… --Remy (Originally)

Back in the heady days of Internet speculation, the giant retailer JumboStores contracted with Fred’s software company, TinyWeb, to develop the region’s first web-based supermarket. Customers would be able to assemble carts online and receive their groceries the next day.

The virtual supermarket had to communicate with JumboStores’s inventory system in real-time. The former was bleeding-edge web technology, the latter a cobweb-laden mainframe with no external point of access.

“How will we get around this?” Fred asked early in the specification process.

“We can stage an intermediate server.” Nick, a programmer from JumboStores IT, assured him around a mouthful of doughnut. “You guys send your requests there, we’ll write software to forward them to the mainframe and back.”
Engine overhauled
Fred was optimistic. Both companies were *nix shops; the JumboStores IT department were his geek kindred. Equally optimistic, JumboStores management scheduled a live media demo several months out, well after the estimated project completion date.

Deadlines slipped, as they are wont to do. The week before the big demo, the online supermarket still wasn’t ready. TinyWeb had implemented the website and database back-end, but JumboStores’ relay software lagged behind. At the urging of multiple strata of nervous managers, Fred took an emergency trip to JumboStores to investigate.

“We don’t know, man, we just don’t know.” The confident Nick of months prior shook now, leading Fred to his cubicle. “We coded the application. We debugged until it compiled without errors. When we run it- core dump!” He threw up his hands, then dropped into his swivel chair. “We’ve been pestering IBM support, but they haven’t been very helpful.”

“Well, why would they be?” Fred frowned, pausing at the cube threshold. “I mean, who knows what might be wrong with the code?”

“Nothing’s wrong with it. It compiles!”

“So? It could still have errors.”

Nick swiveled around to face him. “Dude. It compiles.

Fred faltered in the wake of Nick’s earnest insistence. “That… doesn’t mean the code is perfect.” He all but fell into the spare chair presented to him. “How do I explain this?” Am I actually trying to explain this? To a programmer? “Let’s say you’re building an engine.”

“This isn’t an engine,” Nick said. “It just passes-“

“No, a car engine! OK? You have all the parts spread out on the desk here.” He waved his arm out over a layer of branded cube toys and post-it notes. “You’ve never built an engine from scratch before, but you have a blueprint with pictures and directions, so you grab your wrench and your welder and whatever, and go to town. At the end, all the parts get used up, and the result looks vaguely engine-like. Still, would you expect to drop it under the hood and have it start up flawlessly the first time you turn over the ignition?”

Nick stared. “I… don’t see what this has to do with anything.”

Fred refrained from smacking his forehead. “Uh, OK. Forget the engine. It’s like sheet music. Just because all the dots are on the staff doesn’t mean it’s the song you want.“

“Dude! The compiler would bug out if there were any problems.” Nick graciously omitted the Duh.

Fred took one last chance. “No- it’s like, if you were building a house. Just because all the parts fit together doesn’t mean it will stand up.”

Nick’s face brightened. “It’s like the home inspector! I see what you mean."

“If that works for you…” Fred said, carefully.

After long consideration, Fred took the intermediate server back home to TinyWeb for some down-to-the-wire recoding, resulting in a flawless demo for the press. JumboStores was delighted.

With their collaboration at an end, Fred wondered how JumboStores IT would ever manage on their own.

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

Classic WTF: The Mega Bureaucracy;
Part of the reason we need a summer break is because we simply don't have the organizational skills of this particular company. I wonder if they sell consulting. Original -- Remy

Photo credit: 'digicla' at Flickr At my daytime corporate-type job, if I need to even sneeze in the general direction of a production environment, I need both a managerial and customer approvals with documentation solemnly stating that I thoroughly tested my changes and swear on a stack of MSDN licenses and O'Reilly books that I am NOT going to break anything as a result of my changes. Sure, the whole thing is a pain (and admittedly, a necessary evil), but what Bruce W. has to go through beats the pants off of anything I've ever had to go through.

For the most part, Bruce loves his job. He gets to work with a lot of intelligent and motivated people. He has been developing a new system to support a new product that has the possibility of earning his division several million dollars per year and saving the corporate parent several hundred thousand dollars per year. The net effect on the corporate parent's bottom line will be quite nice. He developed a Web front end while a fellow developer put together the data feeds. The initial development work was estimated to take about six weeks; pretty good since we only had eight weeks to work with.

However, Bruce works in a very large corporation (70,000 plus employees through out the US and several countries) and IT for the corporation has been highly centralized to the world headquarters. Smaller IT work, like the development and support for only a single division, isn't centralized but must pass through the central Mega Bureaucracy for approval and placement on the centralized servers.

...and Bruce needs their "help" to officially set up his environments.

You see, while Bruce and his group can test all day long on their local computers and servers, any kind of "live" environments must be created, blessed, and centralized by the Mega Bureaucracy. They're bigger, badder, and have more connections than anybody in your division's rank-and-file. Remember: in the Mega Bureaucracy, processes and procedures are to be followed, respected, and if necessary worshipped. Oh, and forget even thinking of installing Web services on one of the existing centralized servers. That would bring down the wrath of the entire blessed Bureaucracy for changing the purpose of an existing machine without first going through Mega Change Server Process.

Here's a brief overview of what Bruce had to go through to get four (one each for development, testing, staging, and production) Windows-based Web servers:

Week 1 - At the same time Bruce's group started the project he went to procure the servers. He was told that all he needed to do was put in a Service Request with the Windows Server Team and they would get what we needed. However, that request is cancelled because when the Windows Server Team saw that the servers were for a new application they said, "Whoa, you have violated rule #38,991 of the Mega Bureaucracy! New applications must go through the Process for Application Implementation and Navigation."

Bruce starts into the fill the first two PAIN forms (one being 20 pages long with 150 questions), sends them off to the server team, and immediately receives a response that, no, do not directly send PAIN forms to the group they go to. Instead, open a project with the Mega Bureaucracy's project tracking system, attach the forms and THEN assign the project to the group.

A few days later, he receives word that the project has been accepted, slotted, and a project manager assigned. Bruce figures, "Cool, now we are moving! I'll have my servers in no time!" He and his boss have a conference call with the PM and express to him the time critical nature of these servers. The PM agrees to push them forward saying that the request isn't complex and shouldn't take much effort.

Week 2 - Bruce receives the initial project estimate and immediately replies with his approval.

Week 4 - Bruce calls the PM to find out what's going on. He says that due to staffing cuts only a handful of requests are being processed at a time. Despite being reminded that this project is literally worth millions, he says that other projects are ahead of us and that this is simply how things are. Bruce boss escalates the issue to the head of IT for the entire division who just happens to be a member of the Project Approving Council and supposedly has the power to move the project forward.

Week 6 - Only three weeks until the promised delivery date, Bruce learns that the project still has not moved. His boss fires off a series of emails saying that the app is about to go live on a system that will earn the company millions of dollars that is running on a desktop machine sitting in a cubicle.

Week 7 - The system is now fully coded. Bruce is walking around, shaking his head, saying to himself "We have done user testing and end-to-end testing on a desktop machine-based server!"

Week 8 - The new system goes live and is serving dozens of customers daily. The difference between Production and Test environments is a Post-it Note. Power strips and network hub are carefully labeled "DO NOT TOUCH! HIGH VOLTAGE!" to prevent cleaning staff misfeance.

Week 10 - Bruce and the Windows Server Team finally have the project kick off meeting for the servers. About 15 of the 30 minute call was spent with Bruce repeatedly saying, "All I need is a Windows Server with IIS and .NET. I do not need a database server, no access to the mainframe, no massive SAN space, no Internet access, no interplanetary probe, just servers." "BUT", they say, "You stated on page 16, question 113 that your application uses a database. Where will that database come from?" Bruce explains again, "We are using existing databases assigned to our group. The database is outside of the scope of the project of setting up four Web servers."

Week 12 - Bruce and the Windows Server Team get together for their status meeting. The server team says they haven't budged since last meeting. Why? Everyone says, "Well, we're just waiting for the other shoe to drop and this becoming a big, complex, hairy project requiring massive time." Bruce once again states that all they he needs is four Web servers. Nothing more. The server design engineer says, "Wow, that is pretty simple. Shouldn't take too long at all."

Week 14 - Bruce has another status meeting with the PM and the server engineer. The engineer has put together the required diagram of the requested infrastucture and states that he only had to change a handful of things from the initial template. He says that everything should be ok and once they have the infrastructure readiness, the server builds can start. Bruce thinks, "Finally! All the other people initially assigned to the project must have realized that building four web servers isn't that big if a deal! ...haven't they?"

Week 18 - The head of IT for our division finds out that we are still waiting. Heads start rolling...even poor Bruce's. "WHY DIDN'T YOU CALL ME SIX %($$!*& WEEKS AGO???" the IT head blasts.

Week 19 - The servers are built (it only took 2 days to build them!) and are signed off for production support.

Week 20 - Bruce distributes the application URL pointing to the brand new servers.

Through all of this Bruce learned a couple things. First, don't even think of going around the Mega Bureaucracy, even if somebody says you can. The Mega Bureaucracy remembers and brands you a heretic. Second, if you think you will need help from the Mega Bureaucracy, start early, fill out all of the forms, stand in the right lines, sacrifice to the appropriate gods, and don't even hint that you would think of going around them. Finally, he who yells loudest gets move the front of the queue soonest - as holy and almighty as The Mega Bureaucracy is, they're happiest to get rid of their crabbiest customers first.

The silver lining in all of this? Apparently, the Guardians of the Mega Bureaucracy seem to now be willing to consider that there is a different tier of requests that don't require so many stopping points, designed to make sure that users really, REALLY know what they want to request. Bruce remains positive saying that, maybe in a few years, after meetings to plan meetings, forms to request forms, they will have a process that only has an initial questionnaire of 10 pages and 75 questions.

[Advertisement] Otter - Provision your servers automatically without ever needing to log-in to a command prompt. Get started today!

Classic WTF: The Source Control Shingle;
Our summer break continues. I once worked on a team which made "shingles"- software modules that were layered on top of a packaged product. There were a lot of WTFs in those shingles, but nothing that can compare to this once. Original--Remy

The year was 1999 and the dot-com boom was going full-throttle. Companies everywhere were focused on building revolutionary applications using nothing but top-shelf hardware and state-of-the-art software tools. Developers everywhere were trying to figure out if they should play more foosball, more air hockey, or sit back down on their Aeron and write more code. Everywhere, that is, except Boise, Idaho. Or at least, Dave's small corner of it.

At Dave's company, developers worked at a solid pace, using reliable tools, for a stable industry. They were sub-sub-contractors on a giant project commissioned by the U.S. Navy to condense naval vessel documentation. Generally speaking, the complete documentation required for a modern warship-from the GPS calibration instructions to the giant 130-millimeter cannon repair guide-is measured in tons. By condensing the documentation into the electronic equivalent, they could not only save tremendous physical space, but they could make it much easier to navigate.

A Simple Plan

Dave's company's small piece of the pie involved writing a very specific application for a particular group of users. Their application needed to track who moved which box of classified documentation from where to where, and why. Given the very simple requirements, the entire application was assigned to Mark.

Mark believed in keeping things simple: he rarely left the command line, his text editor was notepad and his source repository was a few backup folders on a network drive. He didn't need or want more than that. It was a simple task that called for his simple methodologies.

As their app neared completion, a whole new set of requirements came in. Now, they had to add in security and logging. When Dave joined Mark's one-man team to help out with this, the current system of source control -- nothing -- became inconvenient for collaborating.

Dave suggested they set up a source-control repository, but Mark wanted to keep things simple. He devised a solution called the "source-control shingle."

Roofing and Revisions

The source-control shingle was literally that: an actual shingle from someone's house that somehow ended up in their office. It acted like a "talking stick," in that only he who possessed the shingle was allowed to edit the common libraries.

As time went on, the project's scope grew immensely. More and more developers came on board, and the source-control shingle was pushed to its limits. Despite not being in possession of the shingle, some developers broke protocol and edited the library files on the share drive. Finally, Mark agreed to use a simple source repository. He wanted to use the only source-control system that guaranteed file locks: Visual Source Safe.

Unfortunately, Source Safe was so painful to license and manage that Mark had no choice but to explore other options, some of which involved a piece of painted wood. After much arguing and cajoling, Mark agreed to try out open source CVS. Things went well for the first few days, but quickly took a turn for the worse.

"What happened to my code?" Mark asked. "I just did a CVS UPDATE and everything I wrote this morning is gone!"

"It's working fine for me," one of the developers replied.

"Same here," another joined in. "I just checked in my changes a few minutes ago, and they're still here."

"Wait," a third one questioned, "did you do an UPDATE before the COMMIT?"

"Did I what?" the second developer replied. "Oh. Crap."

Exasperated, Mark jumped. "That's it! We're going back to the shingle!"

Fortunately, some of the other developers managed to convince Mark to stick with CVS, at least for a little while longer. One of the developers even managed to enforce better source control practices using some server-side scripts. And despite Mark's constant reservations, they ended up staying with CVS throughout the project. But the whole while, Mark kept the shingle handy, just in case.

[Advertisement] ProGet supports your applications, Docker containers, and third-party packages, allowing you to enforce quality standards across all components. Download and see how!

Classic WTF: The Virtudyne Saga;
As we usually do around this time of year, it's summer break season for TDWTF. This week, we're going to rerun some old classics, starting with this legend from 2006, compiled into a single article. --Remy

The Virtudyne saga (published 2006-Oct-10 through 2006-Oct-13) is my all time favorite. It tells the story of the rise and fall of Virtudyne, one of the largest privately-financed ($200M) disasters in our industry. Like most articles published here, all names have been changed to protect the guilty, and I've worked very closely with Rob Graves (the submitter) to ensure that this presentation is as close to how it happened as possible.

Part I - The Founding

By most people's standard, The Founder was very wealthy. A successful entrepreneur since age seventeen, he built several multi-million dollar companies and amassed a fortune larger than that of most A-list Hollywood celebrities. He prided himself on having one of the largest private collections of Egyptian artifacts in the world and prominently displayed many of them in his Great Room. And it truly was a great room: having been to The Founder's mansion several times, Rob recalls that his two-story, four-bedroom home could easily fit inside the Great Room.

The Founder was at home one day, doing whatever retired rich people did in 1999, and became extremely aggravated with how slow his brand-new, top-of-the-line computer was running. While cursing Microsoft Office, he had an "ah-ha" moment: he could build a better Microsoft Office.

Recalling his days as a Digital PDP-11 programmer, he knew that he could write financial software that would support fifty users, perform great, and run in 256-bytes of memory. Given the monumental advances in the twenty-years since he coded, he was elated just to think what would be possible with a bunch of top-notch programmers such as himself. He wondered just how many people it would take to build a Microsoft Office killer.

One thing led to another and Virtudyne was born. Its goal was modest: become the next Microsoft Office killer. The Founder hired his long-time colleague as the Chief Information Officer and together, they would create The Plan. It was simple: develop an internet/intranet based Office/Collaboration system that would deliver "90% of functionality that 90% of [Microsoft Office] users use."

An avid programmer himself, the CIO knew exactly how they could accomplish this. He convinced The Founder that, with a handful of programmers helping him, he could develop a client/server Microsoft Office Killer using Visual Basic 6. And with the latest hardware available, their application could easily scale to support twenty million users using one, maybe two servers. And best of all, it would all take only six months to create.

It was the perfect opportunity to jump on the .com bandwagon. They just could feel the IPO beckoning them. The Founder invested a few million of his own dollars and the CIO started hiring.

One of the first people the CIO approached was Rob Graves. He wanted Rob to become the database administrator, telling him only that Virtudyne was a pre-IPO startup bankrolled by The Founder. As tempting as it was, Rob had a second kid on the way and declined the offer. The CIO would have to find another DBA for the project.

What better place to find a DBA than the same place he turned for the rest of the initial hiring: the local Visual Basic special interest group. In fact, not only did he find a DBA at the SIG, he found one that proclaimed to be one of the greatest DBA in the world. And not because he possessed extensive database administration skills, but because he was willing to admit to The Truth: with the GUI-tools and automagic processes that modern databases offer, all those extensive database administration skills are meaningless.

Sadly, the DBA was one of the more talented members of the initial Virtudyne team.

Part II - The Gathering

The Founder had little trouble convincing his millionaire friends to invest in Virtudyne. It wasn't so much the idea of a Microsoft Office Killer, but that fact that it was 1999 and just about anyone with an internet company could go public and become an overnight billionaire. Within one month of The Founder's grandiose idea, he had secured an impressive eleven million in funding.

While The Founder solicited investors, the Chief Information Officer solicited employees. The CIO knew it would take "only a handful of strong programmers" to develop the Microsoft Office Killer and hired ten of the best programmers he could find. He promised a high salary, good stock options, and the chance to beat the market leader at their own game. Though his team's competence was minimal, their confidence was as strong as ever. They were all eager to build the Microsoft Office Killer.

It was the opportunity of a lifetime handed to the CIO on a silver platter: millions in capital and a dedicated team of developers. It was up to him to get busy with a clear vision, detailed requirements, a throughout market analysis, an extensive design, and solid architecture. Instead, he discovered something much more important: Magic: The Gathering.

The CIO dedicated his "lunch break" to his Magic card collection. This, of course, meant that he'd spend much of his day thinking up new deck concepts, building them, and testing them out. He even got some of his developers hooked: they'd all get together during their "lunch break" and play, trade, and chat about the latest happenings in the world of Magic: The Gathering.

Don't get me wrong, Magic wasn't the Chief Information Officer's only focus. With his new job title, he was eligible to receive executive-level trade publications for free. In fact, one of his first acts as CIO was to purchase a top-of-the-line solid ink printer. In addition to producing sharp full-color graphs for presentation packets, it printed up some wicked high-quality "proxy cards" for everyone's Magic decks.

Days turned into weeks, weeks turned into months, and next thing they knew, six months had passed and not a single line of code had been written. What made this especially bad was the fact that the investors were flying in to town to check on everyone's progress. They were all eager to see just how their Microsoft Office Killer was coming along.

Thank goodness that the Chief Information Officer chose Visual Basic 6 as their platform. Real magic ensued when the following were combined: a handful of developers, a caffeine-filled all-nighter, and VB6's wonderful ability to drag & drop controls onto Windows form and "hard code" what shows in the labels, text boxes, drop downs, etc.

The investors were not impressed. They were astonished. In fact, the demonstration convinced them that, not only the project was on track, but that Virtudyne was poised to take on Microsoft and its ubiquitous office suite. Word spread fast and even more investors signed up. Tens of millions of dollars started pouring into Virtudyne.

The new investment might have been the CIO's motivation to finally get cracking on the project. Or it could have been the fact that the .com bubble was starting to burst and that meant they'd have to make a real attempt at making a product. He immediately started hiring again. And I mean hiring. A massive recruiting campaign was initiated and developers from all over the country were brought in. Within a year, the Virtudyne CIO commanded an army of I.T. professionals whose skill levels ranged between complete ineptitude and moderate competence.

The Chief Information Officer also purchased the best server he could find advertised in his executive trade publications: the Unisys ES7000. It was a thirty-two processor beast with sixty-four gigabytes of RAM and an attached EMC CLARiiON storage server. This $1.3M machine would be the single production server for their anticipated 20,000,000 users.

With all the new talent and the fancy new hardware, development of the Microsoft Office Killer finally began. The biggest hurdle that faced the developers was the new requirements. You see, one of the major selling points to investors was that Virtudyne's office suite already had every feature they asked for: it ran on Windows, Linux, and even Palm OS. All the developers had to do was make it actually do that.

Rob Graves joined Virtudyne around its second-year anniversary. He had been contacting part-time, off-and-on since day one, and they finally made him an offer he could not refuse: lead role in a company of 100+ developers, top-of-the-line development hardware, a dedicated QA team, and most of all, a $50,000 raise with five weeks paid vacation. No one could top that in the post .com-bubble.

In the year that followed, Rob found himself in the middle of quite a few political battles between the "do it right" and the "do it now" developers. Nothing too spectacular, especially in the context of this entire Virtudyne saga, but Rob did note who won the argument over whether or not to use the special coding techniques recommended by Unisys and Microsoft to utilize the server's full potential. I'll let you guess which side that was.

Despite all this, Virtudyne lacked one thing: customers. Allow me to clarify that because saying that they lacked "customers" might imply they had "a" customer. They didn't. The sales department of eight was unable to find a single organization willing to license their product.

This was especially problematic because their initial $94M war chest had dwindled to less than $10M. Investors were starting to wonder about their "six-months-to-develop Microsoft Office Killer" and stopped pouring money into Virtudyne. Something needed to be done.

Part III - The Savior Cometh

Virtudyne's first three years are best summed up with a single word: disastrous. Nearly $90M had been spent developing a product that was barley functional and completely unsalable. Most would call that "miserable failure" and encourage all involved to salvage what they could, abandon ship, scuttle the remains, and never look back. But one person saw it as the golden opportunity; he was known as The Savior

The Savior was a self-made billionaire who struck it rich doing the type of business that makes unregulated industries regulated. He heard about Virtudyne's struggles and wanted to help out. He contacted the powers that be and offered some very reasonable terms. In exchange for investing $100M, he would take over operations and sit as chairman on the board of directors. It seemed to be a a win-win for everyone.

Even the Virtudyne employees were excited. They welcomed their new overlord with open arms and truly believed that The Savior would turn the company around with his "new management team of highly-qualified executives with a proven track record." Such statements tend to be very convincing when accompanied with a hundred million dollar investment.

Unfortunately, employee confidence wore off almost immediately. It wasn't so much that the fact that the superstar executives consisted primarily of The Savior's immediate family, but more the fact that they managed to set the bar of incompetence even higher. I suspect that, given yesterday's article, this might seem impossible, so I'll share my favorite three people that The Savior brought in.

First and foremost, there was the new chief of operations, heralded as a "brilliant innovator" and "technological wizard." He was also The Savior's eldest son. Junior's grasp on technology is best illustrated with this simple anecdote: one day, Junior was walking past Rob Graves' office and saw a graph actively moving around on the screen. He got incredibly exited and wanted to know how he could get the cool looking monitoring software Rob was using to watch their World Wide Server. Rob just didn't have the heart to tell him it was the "Bars and Waves" visulization from Windows Media Player.

One of Junior's first acts as operations chief was to partner up with a major hardware vendor peddling another completely unsalable product. It was a massively-parallel server that featured a proprietary operating system with an integrated database. The sales rep told them that "reliability, not speed, is our primary concern" and they meant it. The $350,000 development server had the same processing power as a 600MHz Pentium II that even a charity organization would refuse as a donation.

Perhaps Junior's logic was that anyone stupid enough to buy the hardware would be stupid enough to buy their Microsoft Office Killer. Unfortunately, Virtudyne seemed to hold a monopoly on the world's supply of stupidity. The expensive hardware and vast amount of effort to port the software resulted in only a single sale, and it was a sale for the hardware vendo to Virtudyner.

The next person on the list was known as The VP of Nothing. I don't that's a very fair title because he actually did two things. First and foremost, despite having no direct reports or job responsibilities, he collected a six-figure paycheck. And secondly, he was allowed to bypass the proxy filter to surf the web; it was no secret why. A curious network administrator looked in the logs and discovered that The VP of Nothing spent a lot of time looking at pictures of large Amazonian women wrestling with little men. Seriously.

My personal favorite that The Savior brought in was The Janitor. Now it may seem odd that the chairman of the board would insist upon changing cleaning companies, but it's even stranger what the new "cleaning company" consisted of: The Savior's youngest son. The Janitor was a trust-fund baby and wealthier than most of us will ever be. It became pretty apparent why he couldn't keep a job anywhere else: after a few months of his cleaning service, ants and cockroaches were everywhere, the VB team had a gnat infestation, and the restrooms became so dirty that most managers allowed their employees to go home if they needed to use the facilities.

Amazingly, this new team was able to find a paying customer. It was The City. Virtudyne's office suite was to be installed at all libraries and made available for download by city residents. All it took was some lobbying at city council, a few calls to the local media, and a sizable march on city hall with "unemployed" protestors demanding the city provide free office software. Although the majority of the protesters were Virtudyne employees, the city finally agreed and signed an $8,500,000 three-year contract, collectable upon timely delivery of the software specified in the contract.

The main problem (well, aside from the fact that Virtudyne's Office Killer was a joke compared to any office suite) was that the contract called for a product that would replace Microsoft Access. In fact, it was a major selling point: the sales VP gave a demo of a product that didn't exist.

It fell on Rob Graves and a handful of other developers to create an application in two weeks that would "allow users with no database and minimal computer knowledge to: build applications; add users and groups to access the application; set security at the form-, record-, and field- level;" and so on. Rob is embarrassed to report that they actually managed to deliver a completely useless application that met every word in the ambiguous requirements to technically fulfill the contract.

None of tha mattered, though. Employee morale was at an all time high and things were finally starting to look good. It only took three and half years and nearly $150M dollars, but they finally made eight and half million dollars. Unfortunately, the sale also brought something else to the Virtudyne: paranoia.

Junior held a company-wide meeting to discuss a very serious issue: Microsoft was onto them. They were shaking in their boots and saw Virtudyne as a major threat. They would stop at nothing to get their grubby hands on the product and might even try to steal the source code. Of course, at that point, about half the people at Virtudyne realized that all one would have to do to "get their grubby hands" on their Microsoft Office Killer was to go into any of The City's public libraries and ask for an installation disk. Obviously, Junior wasn't in that half.

Within days, Junior ordered cameras to cover every square inch of the Virtudyne facility. Fingerprint scanners were installed at every door, both inside and out, and full-time security guards were placed at key locations throughout the building. All exterior windows were covered with a translucent film to prevent Microsoft from peeping in and, just to be safe, computer monitors could no longer face outside windows. Key employees were issued with special pagers that allowed them to discretely press a button to alert the private investigator if they found themselves being followed by Microsoft's white vans.

The draconian security measures didn't help the recent boost in employee morale. In fact, over the next year, employee morale sunk to an all-time low, leading to a mass exodus from the company. Key employees were dropping like flies and all Junior would do to maintain headcount was to hire more employees.

Eventually, Junior struck a good balance between tight security and employee indifference and managed to stabilize the loss. Unfortunately, that didn't help business much. Almost two years had passed since the single sale to The City and Virtudyne couldn't even give away their product. It's hard to say whether it was the terrible product itself or the fact that the Virtydune's contract with The City sparked a state-wide scandal with accusations of impropriety going all around.

What Virtudyne needed was a new market. A market that hadn't heard of Virtudyne before. And preferably, one that wouldn't do any research before spending millions to license their product.

Part IV - The Digital Donkey

After three years of full-time employment at Virtudyne, Rob Graves finally decided to call it quits. Most of Rob's friends and family thought he was insane to leave a cushy job where he was making 30% more than he could anywhere else in town. But then again, most of his current and former coworkers thought he was insane for staying so long.

Virtudyne had blown through nearly $200,000,000 of investor capital over five years to develop their Microsoft Office Killer. All they had to show for it was a barely functional product with a small subset of Microsoft Office's features and a single $8.5M sale. And technically, they only collected $5.8M on the sale because their customer withdrew the contract.

The sales and marketing department were desperate for ideas. They literally couldn't give their software away; anyone with even the most basic knowledge of Google could find out how well Virtudyne's first customer worked out. No one wanted to be their second.

But just then, it dawned on the sales team. They needed to find a market where the Internet had not yet reached. In such a market, their office suite would develop interest and that interest would lead right in to sales. One of the executives knew exactly how to find and penetrate such a market. They would use The Digital Donkey.

The CEO was a bit skeptical at first, but eventually realized how great of an idea it was. It was the perfect plan to sell their product to a market that no one else has ever tapped before. He signed off on the project.

Virtudyne engineers were tasked with figuring out a way to attach a satellite dish, laptops, and solar cells to a donkey. This Digital Donkey would then take Virtudyne's software along with a satellite internet connection to disenfranchised villagers living in the rural parts of India. The villagers would then be able to surf the 'net and use Virtudyne's software suite to create documents and communicate with "God knows who."

Everything would go through Virtudyne's server and they would eventually start billing the local governments for usage. I think it goes without saying that, like virtually every idea coming from Virtudyne's management team, the Digital Donkey was a miserable failure.

Virtudyne's offices are still open to this day, but no one's sure for how long. They've slightly improved their product over the years and tried to sell it under many different names to many different people. But still, nothing seems to work. Rob keeps in touch with a programmer at Virtudyne and confirmed that, as of two or three months ago to this day, there has yet to be a second sale.


Several readers had a hard time believing that Virtudyne actually tried to create a Digital Donkey. It's important to note how ubiquitous donkeys/mules/camels/etc are in everyday tasks and transportation in the third world. So much so that the idea of a "Digital Donkey" did not even originate at Virtudyne. Consider this successful experiment from the International Federation of Library Associations and Institutions:

"The mobile units are Donkey Drawn Electro-Communication Library Carts. Besides functioning as a mobile library with a collection of books and other printed works, it works as a centre for electric and electronic communication: radio, telephone, fax, e-mail, Internet."
-- http://www.ifla.org/V/press/pr0225-02.htm (with pictures, thanks to Antitorgo for finding)

Obviously the Digital Donkey illustration is hyperbolized for fun. What should strike you as unbelievable is not the digital donkey, but the fact that Virtudyne actually considered trying to profiting from such a market. But then again, looking at their track record, that part is not so hard to believe ...

Happy New Year, All! I'll be back on Tuesday, January 2nd with some fresh, new content =-)

[Advertisement] Forget logs. Next time you're struggling to replicate error, crash and performance issues in your apps - Think Raygun! Installs in minutes. Learn more.

Error'd: All the Way from Sweden;

"And to think, this price doesn't include assembly," wrote Adam G.


Martin B. writes, "Don't worry...I'm sure you'll find your group eventually."


"As always I appreciate Google's relevant search results for dealing with specific issues in the office," Michael T. wrote.


Bruce W. writes, "How exactly were podcasts distributed in 1938? 45 RPM Record-of-the-Month club? Also, anyone have have some of those 2038 podcasts?"


"I realize the page says it's 'free', but I don't really think you should be selling that," writes Rob W.


Peter L. writes, "So, does the 's' stand for 'segfault'?"


[Advertisement] ProGet supports your applications, Docker containers, and third-party packages, allowing you to enforce quality standards across all components. Download and see how!

CodeSOD: A Symbol of Bad Code;

As developers, when we send data over the network, we can usually safely ignore the physical implementation of that network. At some level, though, the bits you’re sending become physical effects in your transmission medium, whether it’s radio waves or electrical signals.

You can’t just send raw bits over the wire. Those bits have to be converted into a symbol suitable for the transmission medium. Symbols could be the dots-and-dashes of morse code, tones transmitted over a phone line, or changing duty cycles on a pulse-width-modulated signal. The number of symbols per second is the baud rate of the channel. What this means for digital transmission is that even if your channel has a potential bit rate of one gigabit per second, the actual baud rate may be different- either much larger or much smaller. For example, modems might send 4-bits per symbol, meaning a 2,400 baud modem actually can transmit 9,600 bits per second. GPS, on the other hand, can transmit 50 bits/s, but over one million symbols per second thanks to spread spectrum broadcast.

Marnie works for a telcoms company which greatly cares about these sorts of details. There’s a variety of client-side web apps which accrued over time which can help with things like symbol rate calculations.

For their environment, this calculation is straightforward: whatever the bits-per-second of the channel is, divide by 1.25 to find the symbol rate. Of course, this simple calculation can’t be performed without regexes. Marnie found this code in the code base:

private bandwidthList = [6.4, 3.2, 1.6];
private symbolRateList = [5.12, 2.56, 1.28]; 

public getSymbolRate(_bandwidth: number): string {
	let BW1DecimalPoint = _bandwidth.toString().match(/^-?\d+(?:\.\d{0,1})?/)[0];
	let symbolRate = this.symbolRateList[0];
	let symbolIndex = this.bandwidthList.indexOf(parseInt(BW1DecimalPoint));

	if (symbolIndex > 0) {
		symbolRate = this.symbolRateList[symbolIndex];

	return formatValue(symbolRate);

Now, this is TypeScript, so there is no guarantee that, at runtime, _bandwidth will actually be a number. But there’s no need to convert it to a string, match against a regex, slice up the results, only to parse it back into a an int later. Which, it’s important to note, because they use parseInt inside of the indexOf call, this will never find the target entry inside of bandwidthList- 6 is not 6.4.

So, as written, this method only ever returns 5.12. It’s been in use, in production, for a few years now. Not only is in overly complex, it also just doesn’t work.

Marnie fixed the code with a much simpler version:

public getSymbolRate(_bandwidth: number): string {
	let symbolRate = _bandwidth / 1.25;
	return formatValue(symbolRate);
[Advertisement] Forget logs. Next time you're struggling to replicate error, crash and performance issues in your apps - Think Raygun! Installs in minutes. Learn more.