Last minute geek

last minute tech news from around the net

Monday, Jul 16th

Last update01:00:00 AM

You are here: English WTF


Classif 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."
-- (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.

Read all

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!

Read all

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.

Read all

Reproducible Heisenbug

Illustration of Heisenberg Uncertainty Principle

Matt had just wrapped up work on a demo program for an IDE his company had been selling for the past few years. It was something many customers had requested, believing the documentation wasn't illustrative enough. Matt's program would exhibit the IDE's capabilities and also provide sample code to help others get started on their own creations.

It was now time for the testers to do their thing with the demo app. Following the QA team's instructions, Matt changed the Debug parameter in the configuration file from 4 (full debugging) to 1 (no debugging). Build and deploy completed without a hitch. Matt sent off the WAR file, feeling good about his programming aptitude and life in general.

And then his desk phone rang. The caller ID revealed it was Ibrahim, one of the testers down in QA.

Already? Matt wondered. With a mix of confusion and annoyance, he picked up the phone, assuming it was something PEBKAC-related.

"I've got no descriptors for the checkboxes on the main page," Ibrahim told him. "And the page after that has been built all skew-whiff."

"Huh?" Matt frowned. "Everything works fine on my side."

What could be different about Ibrahim's setup? The first thing Matt thought of was that he'd disabled debugging before building the WAR file for QA.

That can't be it! But it was easy enough to test.

"Hang on one sec here." Matt muted his phone, then changed the Debug parameter on his local deployment from 4 to 1. Indeed, upon refreshing, the user interface went wonky, just as Ibrahim had described. Unfortunately, with debugging off, Matt couldn't check the logs for a clue as to what was going wrong.

Back on the phone, Matt explained how he was able to do reproduce the problem, then instructed Ibrahim on manually hacking the WAR file to change the Debug parameter. Ibrahim reported that with full debugging enabled, the program worked perfectly on his end.

"OK. Lemme see what I can do," Matt said, trying not to sound as hopeless as he felt.

With absolutely no hints to guide him, Matt spent hours stepping through his code to figure out what was going wrong. At long last, he isolated a misbehaving repeat-until loop. When the Debug parameter was set to 4, the program exited the loop and returned data as expected. But when Debug was set to anything less than 4, it made an extra increment of the loop counter, leading to the graphical mayhem experienced earlier.

Horror crept down Matt's spine. This problem would affect anyone using repeat-until loops in conjunction with the IDE. Such programs were bound to fail in unexpected ways. He immediately issued a bug report, suggesting this needed to be addressed urgently.

Later that day, he received an email from one of the IDE developers. I found where it was testing the wrong boolean. Should we raise this as a defect?

"Yes! Duh!" Matt grumbled out loud, then took to typing. And can we find out where this bug crept in? All projects released since that time are compromised!!

As it turned out, the bug had been introduced to the IDE 2 years earlier. It'd been found almost immediately and fixed. Unfortunately, it'd only been fixed in one specific branch within source control—a branch that had never been merged to the trunk.

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

Read all

CodeSOD: Is the Table Empty?

Sean has a lucrative career as a consultant/contractor. As such, he spends a great deal of time in other people’s code bases, and finds things like a method with this signature:

public boolean isTableEmpty()

Already, you’re in trouble. Methods which operate directly on “tables” are a code-smell, yes, even in a data-driven application. You want to operate on business objects, and unless you’re a furniture store, tables are not business objects. You might think in those terms when building some of your lower-level components, but then you’d expect to see things like string tableName in the parameter list.

Now, maybe I’m just being opinionated. Maybe there’s a perfectly valid reason to build a method like this that I can’t imagine. Well, let’s check the implementation.

public boolean isTableEmpty()
    boolean res = false;
    Connection conn = cpInstance.getConnection();
    try (PreparedStatement ps = conn.prepareStatement("select * from some_table")) {
        try (ResultSet rs = ps.executeQuery()) {
            if (rs.first()) {
 	        res = true;
    catch (SQLException e) {
    } finally {
        try {
        } catch (SQLException e) {

    return res;

Even if you think this method should exist, it shouldn’t exist like this. No COUNT(*) or LIMIT in the query. Using exceptions as flow control. And the best part: returning the opposite of what the method name implies. false tells us the table is empty.

[Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!

Read all

Walking on the Sun

In 1992, I worked at a shop that was all SunOS. Most people had a Sparc-1. Production boxes were the mighty Sparc-2, and secretaries had the lowly Sun 360. Somewhat typical hardware for the day.

SPARCstation 1

Sun was giving birth to their brand spanking new Solaris, and was pushing everyone to convert from SunOS. As with any OS change in a large shop, it doesn't just happen; migration planning needs to occur. All of our in-house software needed to be ported to the new Operating System.

This planning boiled down to: assign it to snoofle; let him figure it out.

This was before Sun made OpCom available to help people do their migrations.

I took the latest official code, opened an editor, grepped through the include files and compiled, for each OS. Then I went into a nine month long compile-edit-build cycle, noting the specifics of each item that required different include files/syntax/whatever. Basically, Sun had removed the Berkeley libraries when they first put out Solaris, so everything signal or messaging related had to change.

Finally, I naively thought the pain was over; it compiled. I had coalesced countless functions that had nearly identical multiple versions, deleted numerous blocks of dead code, and reduced 1.4 million LOC to about 700K. Then began the debugging cycle. That took about 3 weeks.

Then I was told not to merge it because another subteam in our group was doing a 9-month sub-project and couldn't be interrupted. Naturally, they were working in the main branch, which forced me to keep pulling and porting their code into mine several times a week, for months. Ironically, they were constantly changing dead code as part of trying to fix their own code.

You can only do this for so long before getting fed up; I'd had it and let it be known to boss+1 (who was pushing for Solaris) that this had to end. He set a date three months out, at which time I would do the merge and commit; other tasks be damned! The subteam was repeatedly informed of this drop-dead date.

So I put up with it for 3 months, then did the final merge; over 3,500 diffs. I went through them all, praying the power wouldn't cut out. After fixing a few typos and running the cursory test, I held my breath and committed. Then I told everyone to pull and merge.

It turns out that I missed 3 little bugs, but they were suffiently visible that it prevented the application from doing anything useful. The manager of the sub-team ordered me to roll it back because they were busy. I handed her the written memo from B+1 ordering me to do it on this date and told her to suck it up and give me a chance to debug it.

An hour later, it was working and committed.

I instructed everyone to pull and build, and to follow the instructions in my handout for coding going forward. Anything that broke the Solaris build would be summarily rolled back per orders from B+1.

It took a few months and hundreds of rollbacks for them to start to follow my instructions, but when they finally did, the problems ceased.

Then the managers from the other teams took my instructions and all my global edit scripts (it wasn't a perfect parser, but it at least left syntax errors if it tried to change code that was really badly formatted, so you could trivially find them and fix them very quickly).

Using my scripts and cheat sheets, my peers on the other projects managed to do their ports in just a couple of hours, and mercilessly rode me about it for the next 3 years.

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

Read all

Error'd: Is Null News Good News?

"The Eugene (Oregon) Register-Guard knows when it's a slow news day, null happens," Bill T. writes.


"12 months for free or a year for not hard to choose!" writes Paige S.


Rodrigo M. wrote, "GlobalProtect thinks the current version I have installed is not very good, so why not upgrade by downgrading?"


"After flying with Norwegian airways I got a mail asking to take the survey," Nathan K. wrote, "Now I apparently need to find out how to file a ticket with their sysadmins."


" name is 'Marketing' now?" wrote Anon and totally not named Marketing.


Brad W. writes, "For having 'Caterpillar,' 'Revolver,' and 'Steel Toe' in the description the shoe seems a bit wimpy."


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

Read all