December 17, 2002
Can CEO greed actually kill people?
Okay, that's an inflammatory statement. But consider the recent ImClone scandal. The company was working on a hot new cancer drug, their stock flew up to $80, and all the shareholders were in heaven. Then the FDA alerted ImClone executives that their drug -- Erbitux -- would not be approved for 2002. Breaking all insider-trading laws, ImClone CEO Sam Waksal alerted his family, dumped his own stock, and even contacted celebrity friend Martha Stewart, who sold $230,000 before the news got out and the stock tanked ... leaving everyday investors holding the bag.
These sordid, venal details are all well known. And many reporters and pundits have thus concluded that Waksal and Stewart and all the other greedy executives were up to no good, and that ImClone got what it deserved.
Unfortunately, there's a whole other bunch of people that got screwed: Cancer patients. In a brilliant story for United Press International, Mary Culpeper Long notes that cancer scientists and advocates worldwide think Erbitux is not a scam. It's the real deal, a genuinely good piece of science and engineering that might save lives:
According to Dr. Harmon Eyre of the American Cancer Society, "there's no question about the fact they've opened a new era."
But Erbitux's success relies on ImClone's success. And ImClone's success relies on its executives operating in honest, good-faith, above-board ways. When Waksal screwed around with his insider trading, he risked messing up ImClone so badly that Erbitux might never make it to market. So you can see where this is going ...
The success of Erbitux and other ground-breaking new medical treatments seems to be inextricably tied to the behavior of corporate executives and the health of their companies. As a result, the health of Americans, in this case those suffering from cancer, is not only in the hands of scientists -- but of corporate executives as well.
Precisely. When Sam Waksal speed-dials Martha Stewart so they can save a couple hundred thousand bucks and afford a more stupidly lavish winter vacation, they're not just being greedy. They're also potentially killing people with their self-serving actions.
Of course, we could be more sympathetic to Waksal. ImClone is a free-market enterprise, after all; Waksal was running a company, not a charity, and there's nothing in his charter that says he has to serve mankind. Quite the contrary. A public company has only one Asimovian prime directive: By law, it must "maximize shareholder value" or get hauled into court. So to be fair to Waksal, he's only doing what businesspeople always do -- playing a risk-taking game in hopes of making more dough. Fair enough.
But one could also ask: Does this arrangement actually serve society? Should we really be developing life-saving drugs using the same marketplace that develops Nike Shox, the Terminator movies, and Cheetos? The free market can be a quite nifty thing, but it frequently forces CEOs to skate on ice so thin it risks destroying their corporations. When lives hang in the balance, is this such a hot idea?
(Note: Zach of Zoombafloom wrote an excellent critique of this posting; check it, and my windy response, out here.)
Posted by Clive Thompson at December 17, 2002 12:09 AM
| TrackBack
Does this arrangement actually serve society?
I don't think you can really answer this question based on the self-serving actions of Waksal and Stewart. These people broke the laws which are "part of this arrangement". Judging a system by a violation of that system is a specious argument which could equally be used to (falsely) justify the dismissal of any hypothetical alternative you might propose.
For example, you might say: "The federal government should pay for pharmaceutical research".
And then, as soon as some civil servant employed by the Ministry of Drugs embezzles a few million bucks from the federal coffers earmarked for said ministry, you might, by your own logic, say "Shit this public funding thing is all wrong. It does not serve society!"
Obviously this would be absurd. But it's formally identical to the argument you're making against the private system.
This isn't to say that you're wrong (though you might be). It just means that if you want to measure the utilitarian benefit of market driven drug research you have to look at its performance against other models, other countries and over time. And you also have to consider the enormous risk and investment involved in this industry.
Besides, suggesting that "They're also potentially killing people with their self-serving actions" is pretty silly.
Good point about the comparison to the governmental situation -- indeed, massive corruption in government-run situations is the yin to the yang of greed-fuelled chicanery in the free market. Neither situation escapes human folly.
Though it's probably fair to ask which one most limits human folly. The point I raised, and which the article I cited slightly raises, is whether the "arrangement" of the free market actually includes corporate chicanery; i.e. does the keep-your-stock-high-at-all-costs prime directive of a public company essentially make lying to your shareholders necessary? I actually think it does, which is why one good corrective some economists have suggested, post-Enron, post-ImClone, post-Tyco, is simply to make it so that it's legal for public corporations to do things that (temporarily, anyway) do not have as their sole goal the maintenance of a top-drawer stock price.
Or another interesting idea is reversing the corporate-salary deduction rule that was set in the 80s. Back after the last bunch of pump-and-dump scandals of that decade, Congress decided that CEOs were being paid too much. To fight it, they passed legislation saying that corporate salaries above $1 million (I think that's the figure, though it might be slightly higher; I maybe remembering it incorrectly) would not be a deductible business expense. They figured this would keep companies from ramming CEO salaries so high.
But it didn't. Instead, companies shifted their compensation away from direct salaries, and onto stock options -- making them essentially invisible to the balance sheet, and the taxman, for corporate purposes. But this only compounded the CEOs' desire to make incredibly stupid short-term decisions that might keep the stock temporarily high, yet in the long run doom the firm, all so that they could cash out.
So another idea being floated is -- why not reverse that rule? Let companies pay their CEOs whatever they want, and get rid of the deduction cap. Maybe we'll go back to the days of $12 million paychecks, but maybe that's a good thing: It makes compensation more visible and thus more easily monitored by shareholders. It also will probably minimize the number of CEOs asking for stock options, making it easier for them to make brave, long-term decisions.
Anyway, the point is -- it's possible to argue that all this CEO malfeasance of late was not a violation of the current marketplace system, but a necessary and kind of inevitable product of it. Cynical, sure, but arguable. I don't necessarily think it means a government-run alternative would be better; that system has its own inherent pitfalls. But if we want to understand the marketplace well, I think we have to get away from a pristine, economics-textbook senses of how it "ought" to run (i.e. fair, open information for everyone, rational decision-making) and grapple with how it actually does run (i.e. frequently unbalanced, riddled with lying, and geared to encourage and -- frequently -- reward chicanery).
But if we want to understand the marketplace well, I think we have to get away from a pristine, economics-textbook senses of how it "ought" to run (i.e. fair, open information for everyone, rational decision-making) and grapple with how it actually does run (i.e. frequently unbalanced, riddled with lying, and geared to encourage and -- frequently -- reward chicanery).
Can't really argue with that, especially now-a-days.
However, if the whole thing is inherently corrupt (this CEO malfeasance of late was not a violation of the current marketplace system, but a necessary and kind of inevitable product of it), how does eliminating a salary cap discourage the manipulation of stock options for ill-gotten profit? Wouldn't you also have to forbid compensating CEOs with options as well?
Yes, good point! I think the question would be not to prohibit options, but to change the taxation compensation such that it makes more sense for corporations to pay salaries instead o of options. Daniel Gross wrote a good piece about this in Slate this summer (actually, it's where I learned about the whole CEO-compensation-limit thing):
Let's imagine, for a moment, that the $1 million limit was rescinded, and paying cash became the most tax-efficient means of compensating top executives instead of the least. Companies would pursue the path of least tax resistance and pay larger base salaries. And the clarity of a salary, its comprehensibility, its easy comparison with our own, would shine a bright light on executive compensation. It would provide a clear picture of precisely which shareholder resources are being doled out to the bosses. Many companies that currently have no compunction about dishing out options grants worth $50 million would not dare to write $50 million checks to top executives. If Enron had disclosed that it paid Jeffrey Skilling and Kenneth Lay $30 million or $40 million salaries, investors and regulators would likely have raised red flags far earlier. And if Enron cut back on its lavish stock options, Skilling and Lay might not have used accounting trickery to boost the company's share price.
Sold . . .
(and thanks for the "plug")
Good point about the comparison to the governmental situation -- indeed, massive corruption in government-run situations is the yin to the yang of greed-fuelled chicanery in the free market. Neither situation escapes human folly.
Since the Heap has no definite rules as to where it will create space for you, there must be some way of figuring out where your new space is. And the answer is, simply enough, addressing. When you create new space in the heap to hold your data, you get back an address that tells you where your new space is, so your bits can move in. This address is called a Pointer, and it's really just a hexadecimal number that points to a location in the heap. Since it's really just a number, it can be stored quite nicely into a variable.
Let's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.
Note first that favoriteNumbers type changed. Instead of our familiar int, we're now using int*. The asterisk here is an operator, which is often called the "star operator". You will remember that we also use an asterisk as a sign for multiplication. The positioning of the asterisk changes its meaning. This operator effectively means "this is a pointer". Here it says that favoriteNumber will be not an int but a pointer to an int. And instead of simply going on to say what we're putting in that int, we have to take an extra step and create the space, which is what does. This function takes an argument that specifies how much space you need and then returns a pointer to that space. We've passed it the result of another function, , which we pass int, a type. In reality, is a macro, but for now we don't have to care: all we need to know is that it tells us the size of whatever we gave it, in this case an int. So when is done, it gives us an address in the heap where we can put an integer. It is important to remember that the data is stored in the heap, while the address of that data is stored in a pointer on the stack.
That gives us a pretty good starting point to understand a lot more about variables, and that's what we'll be examining next lesson. Those new variable types I promised last lesson will finally make an appearance, and we'll examine a few concepts that we'll use to organize our data into more meaningful structures, a sort of precursor to the objects that Cocoa works with. And we'll delve a little bit more into the fun things we can do by looking at those ever-present bits in a few new ways.
This will allow us to use a few functions we didn't have access to before. These lines are still a mystery for now, but we'll explain them soon. Now we'll start working within the main function, where favoriteNumber is declared and used. The first thing we need to do is change how we declare the variable. Instead of
This is another function provided for dealing with the heap. After you've created some space in the Heap, it's yours until you let go of it. When your program is done using it, you have to explicitly tell the computer that you don't need it anymore or the computer will save it for your future use (or until your program quits, when it knows you won't be needing the memory anymore). The call to simply tells the computer that you had this space, but you're done and the memory can be freed for use by something else later on.
But variables get one benefit people do not
Note first that favoriteNumbers type changed. Instead of our familiar int, we're now using int*. The asterisk here is an operator, which is often called the "star operator". You will remember that we also use an asterisk as a sign for multiplication. The positioning of the asterisk changes its meaning. This operator effectively means "this is a pointer". Here it says that favoriteNumber will be not an int but a pointer to an int. And instead of simply going on to say what we're putting in that int, we have to take an extra step and create the space, which is what does. This function takes an argument that specifies how much space you need and then returns a pointer to that space. We've passed it the result of another function, , which we pass int, a type. In reality, is a macro, but for now we don't have to care: all we need to know is that it tells us the size of whatever we gave it, in this case an int. So when is done, it gives us an address in the heap where we can put an integer. It is important to remember that the data is stored in the heap, while the address of that data is stored in a pointer on the stack.
When the machine compiles your code, however, it does a little bit of translation. At run time, the computer sees nothing but 1s and 0s, which is all the computer ever sees: a continuous string of binary numbers that it can interpret in various ways.
Inside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.
