Tag: software

The Cost of Comp Plans

By James Kwak

Enterprise software is the industry that I know best. Both of the real companies I worked for (sorry, McKinsey is a fine institution in many ways, but it isn’t a real company) were in enterprise software: big, complicated, expensive software systems for midsize and large companies that can take years to sell.

Although the development of enterprise software is (often) highly sophisticated, sales is typically governed more by tribal custom. One trait we probably shared with other big ticket, business-focused industries is the “comp plan”: the system for calculating salespeople’s commissions on sales. The comp plan is just about the most important thing to any red-blooded salesperson. (Its only competition would be the territory assignment, which determines what companies he is allowed to sell to—or, more specifically, for sales to what companies he will earn a commission.) It is the source of months of lobbying, the subject of intense executive- and even board-level scrutiny, and the target of almost every complaint.

Continue reading “The Cost of Comp Plans” →

With Great Power . . .

By James Kwak

A friend brought to my attention another example of how Excel may actually be a precursor of Skynet, after the London Whale trade and the Reinhart-Rogoff controversy. This comes to us in a research note from several years ago by several bioinformatics researchers titled “Mistaken Identifiers: Gene name errors can be introduced inadvertently when using Excel in bioinformatics.” The problem is that various genes have names like “DEC1” or identifiers like “2310009E13.” When you important those text strings into Excel, by default, the former is converted into a date and the later is converted into scientific notation (2.310009 x 10^13). Since dates in Excel are really numbers behind the scenes (beginning with January 1, 1900), those text identifiers have been irretrievably converted into numbers.

This problem is related to what makes Excel so popular: it’s powerful, intuitive, and easy to use. In this case, it is guessing at what you really mean when you give it data in a certain format, and most of the time it’s right—which saves you the trouble of manually parsing text strings and converting them into dates (which you can do using various Excel functions, if you know how). But the price of that convenience is that it also makes it very easy to make mistakes, if you don’t know what you’re doing or you’re not extremely careful.

There are workarounds to this problem, but as of 2004, it had infected several public databases. As the authors write, “There is no way to know how many times and in how many laboratories the default date and floating point conversions to non-gene names have adversely affected an experiment or caused genes to ‘disappear’ from view.”

Frat Boys and Tech Companies

By James Kwak

Matt Bai’s recent article on how Curt Shilling’s gaming company, 38 Studios, managed to secure a $75 million loan from the State of Rhode Island and then flame out into bankruptcy is a reasonably fun read. Bai’s main emphasis, which I don’t disagree with, is on Rhode Island’s Economic Development Corporation, which managed to invest all of its capital in a single company in a risky industry that, apparently, had failed to secure funding from any of the VC firms in the Boston area. Overall, this seems like another example of why government agencies shouldn’t be trying to act like lead investors.

But the story has another moral, which struck closer to home for me. Shilling apparently founded the company because he liked MMORPGs and because he wanted to become “Bill Gates-rich.” When the going got tough, in Bai’s words, Shilling “seemed to think that he could will Amalur into being, in the same way he had always been able to pitch his way out of a bases-loaded jam, even with a throbbing arm. His certainty reassured employees on Empire Street, who had no idea that he was running out of money.”

Software is hard. Really hard. And it’s even harder when you’re up against good competition. It has to be done right, and you cannot get it done twice as fast by working “twice” as hard. Too many software companies have been run into the ground by people who wanted to make a fortune but had no understanding of how software is built. Most of them are back-slapping frat boys who climbed the corporate hierarchy in sales, not world-famous athletes. But Curt Shilling, apparently, was just like them.

The Importance of Excel

By James Kwak

I spent the past two days at a financial regulation conference in Washington (where I saw more BlackBerries than I have seen in years—can’t lawyers and lobbyists afford decent phones?). In his remarks on the final panel, Frank Partnoy mentioned something I missed when it came out a few weeks ago: the role of Microsoft Excel in the “London Whale” trading debacle.

The issue is described in the appendix to JPMorgan’s internal investigative task force’s report. To summarize: JPMorgan’s Chief Investment Office needed a new value-at-risk (VaR) model for the synthetic credit portfolio (the one that blew up) and assigned a quantitative whiz (“a London-based quantitative expert, mathematician and model developer” who previously worked at a company that built analytical models) to create it. The new model “operated through a series of Excel spreadsheets, which had to be completed manually, by a process of copying and pasting data from one spreadsheet to another.” The internal Model Review Group identified this problem as well as a few others, but approved the model, while saying that it should be automated and another significant flaw should be fixed.** After the London Whale trade blew up, the Model Review Group discovered that the model had not been automated and found several other errors. Most spectacularly,

“After subtracting the old rate from the new rate, the spreadsheet divided by their sum instead of their average, as the modeler had intended. This error likely had the effect of muting volatility by a factor of two and of lowering the VaR . . .”

Continue reading “The Importance of Excel” →

More Bad Software

By James Kwak

Last week BATS admitted that its software suffered from systematic problems for four years, failing to obtain the best execution price for about 250 customers and costing them about $400,000. That should be a giveaway: no self-respecting company would break the law just to steal $400,000 from its customers. This was a programming error, pure and simple.

Also last week, a RAND study revealed that, despite billions of dollars of investment, electronic medical records have done little to reduce costs for healthcare providers. This is more complicated than a simple programming error. The issue here is that projected savings of this kind are typically based on some model of how operations will be done in the future, and that model depends on perfectly-designed software functioning perfectly. Medical records systems apparently fall far short of this ideal: as the Times summarized, “The recent analysis was sharply critical of the commercial systems now in place, many of which are hard to use and do not allow doctors and patients to share medical information across systems.”

The common feature to these stories, however, is that big, complex, business software is really, really important—and a lot of it is bad. In many niches, it’s bad because there aren’t that many companies that serve that niche, it’s hard for customers to evaluate software that hasn’t been delivered and installed yet, and there are all sorts of legacy problems, particularly with integration to decades-old back-end systems. And most of the incentives favor closing the sale first rather than making sure the software works the way it should.

I don’t have much to add that I didn’t put in my Atlantic column on a similar topic last summer. Nothing has changed since then. So I’ll stop there.

The Problems with Software Patents

By James Kwak

Charles Duhigg and Steve Lohr have a long article in the Times about the problems with the software patent “system.” There isn’t much that’s new, which isn’t really a fault of the article. Everyone in the industry knows about the problems—companies getting ridiculously broad patents and then using them to extort settlements or put small companies out of business—so all you have to do is talk to any random group of software engineers. And it’s not as much fun as the This American Life story on software patents, “When Patents Attack!” But it’s still good that they highlight the issues for a larger audience.

The article does have a nice example of examiner shopping: Apple filed essentially the same patent ten times until it was approved on the tenth try. So now Apple has a patent on a universal search box that searches across multiple sources. That’s something that Google and other companies have been doing for years, although perhaps not before 2004, when Apple first applied. There’s another kind of examiner shopping, where you file multiple, similar patents on the same day and hope that they go to different examiners, one of whom is likely to grant the patent.

Continue reading “The Problems with Software Patents” →