I’m going to take a little diversion from discussing Go code today in order to share a curious story from the history of computing.

What Was MiniScribe?

MiniScribe was established in 1980 as a manufacturer of computer hard-disk drives, an important supplier to the fast-growing tech industry.

The company’s motto was “Solutions for Data Storage”, since its expertise was focused entirely in the area of developing disk drives for the burgeoning PC market.

This was cutting-edge technology, since the first generation of personal computers often didn’t have a hard-disk drive at all: they used tape or floppy disks for storage.

Their very small storage capacity meant that users often had to use multiple floppy disks in order to load complex items of software, swapping one disk for another when prompted by the machine.

So MiniScribe’s internal HDDs were genuinely revolutionary, because they allowed programs to be stored and loaded from the machine itself.

Previously, the Operating System had often been built in to the motherboard (in the way that a modern BIOS is), but all other applications would have needed to be loaded from external storage.

The Decline of the Company

Despite its products seeming so promising, MiniScribe would be destined to collapse within a decade of its launch after it was found to be involved in an almost improbable scheme of fraud.

The company was affected by two crises, both at the same time.

The first major problem was that consumers were rapidly moving away from the 5.25-inch disk drives that MiniScribe had innovated, in favour of smaller 3.5-inch drives.

Secondly, and perhaps more importantly, MiniScribe had lost an important contract with International Business Machines, usually known by the acronym IBM, which had an even more important position in the computer industry than it does now.

IBM was attempting to produce its own hardware, in the hope of becoming less reliant on its suppliers.

Playing a Dangerous Game

Executives at MiniScribe were understandably concerned about the losses that the company was incurring, but rather than being honest with their customers, regulators and investors, they decided to take a big gamble in an attempt to save the own jobs.

They claimed to have much more inventory than they actually had, inflating the real figure by around fifteen million dollars.

They altered the company’s own internal records, but what was even more audacious is that they sent someone to break into the premises of an auditing firm to doctor their records too. This ensured that the false information would be distributed consistently.

However, they still had one big problem: they needed to be able to provide an explanation if anyone asked where the imaginary inventory was.

Putting Bricks into Boxes

So the executives at MiniScribe hired a warehouse as a location that they could claim housed the phantom stock.

But, of course, the stock didn’t exist, so they needed something to take its place. They filled cardboard boxes with the sort of red bricks that are used in construction.

In fact, they stored around 26,000 bricks in boxes, and each box was assigned its own serial number.

Hoping that no one would bother to open a box and look inside, they assumed that this clever — or foolish — ruse would be enough to back up their falsified accounts.

The management of MiniScribe even colluded with two of their best customers, the companies CompuAdd and CalAbco, intending to send the boxed bricks to them, in order to make the nefarious scheme seem more legitimate.

The Ruse Is Uncovered

This fraud only made the difficulties at MiniScribe even worse. The accounts showed that the company was prospering, and investors were therefore happy to continue supporting it, but in reality it was haemorrhaging money.

The company could not afford to pay its suppliers, and things had become so bad that its employees weren’t even receiving their basic salaries.

Since the expectations of outside observers for the company were so high, the initial fraud required even greater degrees of fraud to be committed, simply in order to keep up the illusion.

When the CEO finally resigned, the new chief executive quickly realized what had happened: he was forced to inform the market that MiniScribe had, in fact, accrued undeclared losses of around one hundred million dollars. 

Lessons From the Downfall of MiniScribe

Given the scale of its accounting fraud, investors, auditors and regulators could have seen that MiniScribe was holding a much greater proportion of stock, in relation to the sales that it had reported, than its competitors were. This alone should have been a warning sign.

Many hardware companies attempt to keep inventory levels as low as possible, because improvements in technology can soon make older models outdated.

The ruse that was attempted by the management at MiniScribe reminded me of the idea of a Potemkin village, which were said to be pseudo-settlements made up of wooden facades, like a stage set, created to give the appearance of a more prosperous Russia when Empress Catherine II travelled across her country.

The story probably isn’t true, but that doesn’t matter, because there have been real-world examples of such settlements being built.

For example, the North Korean village of Kijong-dong, based a few miles from the territory of South Korea, is considered by many to be a “Propaganda Village” that is entirely uninhabited, maintained merely to give the illusion of prosperity to viewers from across the border.

It’s natural in diplomacy and warfare to want to outwit the enemy, even by devious means, but taking such an approach in business can backfire catastrophically.

As the old adage goes, if something looks too good to be true, then it probably is. Estimates of costs and deadlines for coding projects are notoriously unreliable, often because the scope of the project increases as new features become necessary.

Programmers and web developers sometimes take shortcuts in their code, too, ignoring edge cases that seem unlikely to arise or not giving proper attention to accessibility or backwards-compatibility issues.

Sometimes these shortcuts can be justified, but it’s always worth considering if perhaps you’re just attempting to do the software-development equivalent of stacking bricks into boxes and hoping that nobody ever finds out.

But the bricks will tumble out eventually.