Skip to content

Archive for

Share Price Manipulation

If insider trading, press release puffery, and “earnings smoothing” are the tools used to prop up a share price, then frivolous class action lawsuits must be the tool to kill the share price. I received a letter today notifying me of yet another class action settlement from the boom years – this time related to Cisco shares. As with all the others, I waded through the settlement procedure and perused the proposed settlement per share.
This one?? Approximately 9 cents per share, less any court approved fees. The alleged crime? Share price manipulation. The lead plaintiffs feel this is a good settlement. They must be smoking crack and getting kickbacks from the attorneys. What a bunch of crap. I can’t imagine what they’re thinking – could it be that Cisco or its agents went out of its way to inflate the share to $55, but $54.91 was a fair price?? That’s basically what the plaintiffs are saying here. What a load of BS.
And who really gets hurt?? If anyone, it’s the current shareholders. The ~$100 million that it’s going to take to settle the suit is coming out of their value. Oh, and I feel hurt because I spent 5 minutes reading over the materials, 10 minutes being pissed off about it, and another 10 minutes sharing this with all of you. The upshot?? Monday Night Football starts in a few minutes. I don’t know who is playing, but it’s got to be more entertaining than reading, thinking about, and blogging about lawyer drivel.

A Funny Thing Happened While Debugging Code Today

When testing new code, we often use names of baseball players, football players, etc in order to make it a point that the information we are entering is bogus data. It also gives us an easy way to differentiate test cases and say something like “Pujols can’t change his email address.” Until yesterday, this had never been an issue for me.
So I get the phone call that “The last three mornings I have had to the clear the cache for [big name star].” No big deal, I think. We’ve been having an issue with cached transactions ever since we upgraded this application a few months ago. Out of 40,000+ people, it only affects about 9 per month. I thought this was just reporting a new twist on the problem.
I logged into the database to start troubleshooting, found the header record, found the child record causing the problem and was finally able to figure out what has been plaguing us for the past 2 months. If it was the first time a user accessed the system, the flawed child record was not written. However, if a cached header record existed previously, it was purged and a new header and new flawed child record was created. So I put in a patch that would check if cache was pre-existing, check to see if the child record was flawed (the flaw was created by a closed system I have no access to, so I had to work around it), and write things out accordingly.
After putting the patch in, I checked the header for my test user. Wait – this isn’t the [big name star] test user I created. [Big name star] was actually a customer — and he actually was having a problem (or at least his financial manager was). What are the odds on that?