Posts Tagged ‘Financial Industry’

From the Annals of Dubious Achievement

It is I who wrote RichardIsAFuckingIdiotControl, voted the "best comment in source code … ever encountered" in this StackOverflow question. I didn't submit it, nor do I know the person that did. (I came across it on reddit, or something. I don't have the will or personal bandwidth to participate in something like StackOverflow.) This happened at a former employer.

I am not sure that I am proud of this. Actually I'm pretty sure that I'm not proud of it. But I'll explain what the deal was for the record anyway. I am also not sure that this deserves the "accolades" that it received. After all it's not technically a comment (although it contains some doozies) and I would never have chosen pure vitriol over, say, something from Ritchie's Odd Comments and Strange Doings in Unix.

Obviously what sets this apart from other snippets in the genre is the over-the-top hatred of a very specific colleague. So let me tell you a little about Richard.

First, his name wasn't Richard. Whoever submitted the sample was wise enough to change that (thanks, guy). I didn't even use his given name in the original source, although it was a moniker that most people would have understood. "Richard" was no longer employed by the company when I wrote this. He had recently been fired for repeatedly showing up in the early to mid-afternoon drunk and coked out of his mind (I guess nobody told him that we real programmers show up on time and drink at our desks).

Richard was a recent college grad with roughly a 1.8 GPA from a decent-but-not-prestigious CS program. Miraculously (if you're Richard), someone decided he was a "cultural fit" and therefore deserved $70K per year. For readers who have only ever been exposed to polite society, it is important to note that this is standard practice in the financial industry and is considered "normal." Around this time, I had gotten a little bent out of shape about hiring for various reasons that I won't go into, and I was the asshole. Go figure.

Personally, there is only one word that describes the kid. That word is broseph. If I were to call him a violent, drug-addled menace, it would not be hyperbole. Let me say it again, "cultural fit."

After Richard's exit, I had to take over his code. I wound up rewriting almost all of it from scratch, and this class was serving as a blast shield around the volatile remains of what I could salvage. Honestly, at this point I was bored to tears, and a lot of what I did was probably total crap. If there's any justice, right now someone's writing a profanity-laden class with my name all over it.

But anyway, let’s go over the code. I’ll add some color, where I can remember what was going on.


// The main problem is the BindCompany() method,
// which he hoped would be able to do everything. I hope he dies.

I am firmly opposed to the death penalty, but if a piano fell on his head I would be sincerely happy. (And again, for some reason I'm the asshole.)


public void BindCompany(int companyId) { }

// snip

private void MakeSureNobodyAccidentallyGetsBittenByRichardsStupidity()
{
    // Make sure nobody is actually using that fucking bindcompany method
    MethodInfo m = this.GetType().GetMethod("BindCompany", BindingFlags.DeclaredOnly |
        BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic);
    if (m != null)
    {
        throw new RichardIsAFuckingIdiotException("No!! Don't use the fucking BindCompany method!!!");
    }
    // P.S. this method is a joke ... the rest of the class is fucking serious
}

There was some deeply-entrenched reason why I could not change the definition of the BindCompany method. It had to be there, but the code paths that called it were all fundamentally flawed, or something like that. I decided to be funny and use reflection to raise an exception if anyone happened to redefine with an implementation of it in a derived class.


/// <summary>
/// This returns true if this control is supposed to be doing anything
/// at all for this request. Richard thought it was a good idea to load
/// the entire website during every request and have things turn themselves
/// off. He also thought bandanas and aviator sunglasses were "fuckin'
/// gnarly, dude."
/// </summary>
protected bool IsThisTheRightPageImNotSureBecauseRichardIsDumb()
{
    return Request.QueryString["Section"] == this.MenuItemKey;
}

One of the really crazy things about this application was that for every web request, it would actually load several hundred control classes and call methods on them. Maybe two or three of these would actually be necessary. They would all determine (based on the URL, I think) if they were supposed to be drawing anything. It would have been much easier to, god I don't know, just call the methods that were necessary to draw each page. I still have nightmares about this ridiculous contraption every now and then.

I guess the StackOverflow snippet doesn't capture this, but the best thing about Richard's code was that he loved property getters and setters. No, wait, that's not quite right. Lots of people love getters and setters, but Richard seemed to be in love with getters and setters. So much so that about 70% of his logic took place in them. More than once I deleted code that looked like this:

foo.x = foo.x;

Only to break entire pages, because the side effects of that assignment were doing everything. Anyway, I hope you can all see where I was coming from now.

And we’re back

So, I have finally fixed this stupid site. I spent years devising plans for rewriting it in lisp, or something, then one day read this essay about perfectionism and decided I was being completely ridiculous. Yes, that is my dog in the header, thank you for asking.

Some would have balked at the prospect of hand editing years of predominantly embarrassing posts, but I soldiered on through good times and bad. I am still messing with the layout and I haven’t even looked at the damn thing in Internet Explorer yet. (If you have IE—I don’t at home—let me know if something is really messed up.)

Evidently, once upon a time I had a career writing a lot of code for various Microsoft platforms. I feel like that part of my life needs to remain there for posterity, even though I am very happily participating in the open source, OMG-scale web world these days.

If I leave those posts there, perhaps someday someone can explain them to me. Very few of them make any sense to me now. I do remember fielding the e-mail from the ignoramus I-banker that prompted me to write Significant Digits for the Inummerate. With a little luck, his life is now ruined forever.

I thought I would miss debugging obscure threading issues, and rooting through core dumps, and staring at disassembly, but I was wrong. I have come to appreciate the sublime beauty of fork, the challenge of writing code for epic scale, having the damn source code, and solving problems that matter to people that are not evil mutants. I haven’t hand-edited XML in two years. Life is beautiful. Hopefully with the whole “blog” issue out of the way I will be able to think of something interesting to talk about.

What is Dan Doing?

Hey, by the way, the last post is likely to be my last Windows-oriented post for the forseeable future. I have recently quit the financial sector and will be starting a fantastically cool new job here in a few weeks. I no longer have a Windows machine at home at all, so unless I take up Mono, expect a lot of posts that mention emacs from now on. I think this will be for the best, since I've been kind of bored and nonplussed with .NET stuff lately, F# notwithstanding.

Giving up on Microsoft development entirely was a little bittersweet until someone showed me XMLScript a week or two ago–clearly, a lot of people in that world are out of their god damned minds. Best of luck writing xhtml-serving web applications defined in xml markup with client script written declaratively in more xml, also exposing xml web services to rich client applications defined largely in XAML, updated automatically as defined in xml configuration files, to those of you lucky enough to get to do this.

Reverse Job Advertisement

I figured this was worth a shot.

I am:

  • Someone that has been hacking since childhood.
  • Someone that has spent most of his Saturday doing problems in a Haskell textbook for fun.
  • Someone that thinks programming is very similar to art, if one is sufficiently good at it.
  • Compelled by forces beyond my control to refactor code until it is elegant.
  • Equally comfortable debugging disassembly, arguing with you about math, and frantically scribbling on your whiteboard.
  • Able to debug your problem. Trust me.

You are:

  • An early stage startup led by software people.
  • Located in Manhattan or Brooklyn, or your idea is so incredibly exciting that I am willing to relocate to participate in it.
  • Not using Java, Visual Basic, or other such variants of COBOL.
  • Able to pay me, so that I can continue to pay my rent and avoid subsisting on boiled newspaper. This either means that you are funded, or you have a very clear idea of how you are going to make money.
  • Not an egomaniac.

If you think that you fit this description, please contact me at mcfunley at (google's mail service).

A Real Head-Scratcher Courtesy The CLR And Office Teams

"Why the hell is this application insisting on loading an old version of the CLR?" I'm guessing that's what you're asking yourself if you've gotten here through your search engine of choice. Well, relax. I'm about to explain.

It is reasonably well-known that there are .config file settings that can force an application to load a specific CLR version. It is also possible to write unmanaged code using the hosting API's like CorBindToRuntimeEx to bind to a specific version. I'm not talking about either of these scenarios.

There is a set of undocumented (as far as I know) registry keys that can override either of these vectors. They are located here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\AppPatch\v2.0.50727.00000

If you take a look at this key on your own machine, you'll probably see a handful of applications listed.

The root of the Microsoft Office .NET Framework version bug

Applications can specify a target version of the framework that will be loaded into the process, even if there is no .config file present, and even if you write some C++ to call CorBindToCurrentRuntime. Mscoree will simply report that the current runtime is 1.1.4322, even if the user has 2.0 installed on their machine. This is, I suppose, superfically similar to the strategy used in the Image File Execution Options built into NT.

I can see where this would be handy–presumably Microsoft has a handful of .NET 1.1 apps in the wild that showed bugs against 2.0, and it's not exactly practical or foolproof to try to drop a .config file on those apps when installing the framework (naturally, somebody can just install the application after the framework, then be puzzled as to why it isn't working).

Good solution, right? It's a shame they fouled it up.

Notice that Word and Excel are both listed as special applications on my machine. I have these values on my laptop:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\ AppPatch\v2.0.50727.00000\excel.exe\{2CCAA9FE-6884-4AF2-99DD-5217B94115DF}]
"Minimum File Version Number"="11.0.0.0"
"Maximum File Version Number"="11.0.9999.9999"
"Target Version"="v1.1.4322"

It appears as though the someone is trying to force a relatively older build of Excel/Word 2003 to load v1.1. Fair enough, the Excel build on my machine is up to 11.6 at this point. Unfortunately, those developers failed miserably in the attempt. Every single other application listed under AppPatch in my registry looks like this:

"Minimum File Version"="11.0.0.0"
"Maximum File Version"="11.0.9999.9999"
"Target Version"="v1.1.4322"

When the version filter isn't specified (or actually in this case, miswritten as "Minimum/Maximum File Version Number" instead of "Minimum/Maximum File Version"), all versions of the executable will load the target version. So these keys effectively break 2.0 addins for all versions of Word and Excel.

There is an update available that fixes this issue, here. The KB article that accompanies it doesn't really explain what the issue is, which is why I've summarized it here. Office update is not exactly an automatic affair like its Windows counterpart, so this bug makes it essentially impossible to write a fault-free Office addin that targets 2.0 and does not hack up the user's registry upon installation. I can't say I advocate doing that, but I would understand if you did. As for myself, I am most likely going to target 1.1 much longer than I had hoped would be necessary.

Choose Your Constants Carefully

You never know what will become an API.

DarrelHerbst: did you make the annotated stock chart left link have linkId=666 on purpose?
McFunley: yes
DarrelHerbst: it looks really cool in this document i'm writing

I’m All Sixes and Sevens and Nines

The following is a review of A Mathematician Plays the Stock Market, by John Allen Paulos.

One of my inaugural tasks at my current job was developing a technical analysis package for market data. I have to admit I rather enjoyed this, for a few reasons only tangentially related to the specific technology at hand.

First, I like solving math problems–always have. Writing programs that do this for me are more enjoyable still. Second, there was the shameful thrill of scrawling some equations involving capital sigmas (the kind of thing those of us destined to be computer scientists are doing by eighth grade) on a whiteboard and watching the panicked expressions of the business and finance people present.

I guiltily concede that the latter motivation was the dominant one. I still keep a sheet with sigmas painted all over it within reach. Anytime I’m asked about the output of my analysis package, I produce it from deep within my desk which by the way, overwhelmingly contains only ketchup (Heinz) and straws (plastic, non-bending). I’ll scribble some new symbols on it and say something like, “so as you can see, the limit of this term as phi approaches infinity is…” and before I’ve finished the sentence the person has muttered something in bewilderment and shuffled away.

dice

I’m not necessarily doing this out of malice or contempt, it’s just that I realized a long time ago that the technical analysis of market data is largely a crock. I’ve always carried this nagging little fact with me, and at times I’ve pondered the morality of having this job at all. So I’m not really doing the user a disservice here, unless I’m somehow expected to explain to everyone in the world that you can find meaningful patterns in any set of data–words in the bible, petals on a flower, sand on the beach, or the price of Superconductor (NasdaqSC:SCON). Chances are, the pattern that you discover holds no predictive power.

So it’s really not important to the person asking what the answer is, it’s just reassuring to believe that I possess one. In the end, they will probably make about as much money as chance would dictate. Maybe a little more, maybe a little less. If they do happen upon the holy grail, that ineffable oracle of a model that really can forecast the future, it is as likely to be in spite of my explanation as it is to be caused by it. Populus vult decipi; decipiatur.

How odd it is, I found myself thinking while reading this book, that there exists a Nobel prize for Economics yet none for Mathematics. Is my support for this book just another example of confirmation bias? I’m obviously not qualified to say. I suggest you judge it for yourself.

A Meandering Static Locals Story

I was writing some C# code the other day and attempted to use a static local variable. This may only be because I've been spending so much time with C++ recently, but I was very surprised to find that it didn't work. "That's a shame," I thought. It's not as though I use static locals every day. I've been using C# for a few years and I was just getting around to discovering that it doesn't support them, after all. Nevertheless, I would say I use static locals exactly when I need them.

I was sure that VB.NET supported static locals. I thought that perhaps an Object Orientation zealot decreed that they weren't going into C#, even though that would not be typical of the attitude exhibited in the most recent C# whitepapers. As it turns out, that's not what happened at all. Static locals are a compiler feature, and not something implemented on the CLR level. Paul Vick explains:

Implementing static locals in the compiler was a gigantic pain in the ass, and we had a lot of arguments about whether they were worth the effort. There are times that I haven't been entirely convinced about it, but I think my thoughts on this are changing…

I suppose I have already conceded that there are more important things to spend time on. In the same post Paul discusses the relative merits of the keywords in either language.

We also felt that “Shared” is a lot more descriptive than “Static,” and I wonder whether C# would have chosen that term if they hadn't been stuck with the legacy of C, but… This is probably the most painful keyword divergence between the two languages in terms of documentation.

Something of a silly discussion, I think, since VB is teeming with its own historical oddities (to wit: Dim intArray(0) As Integer). But this does remind me of a story.

A while back I was debugging an odd issue where users of a web application were seeing each other's data "randomly." Our application has a set of links on one side of it that are customized to relate to the entity the user is viewing. A typical bug would be:

The top half of the links relate to entity 'A' (which is the right one), but the bottom half of the links relate to entity 'B,' which I was not looking at.

Compared to some other bugs I have worked on, this one was a piece of cake. I figured out pretty quickly that the developer of the control in question had written a big section of variables that looked like this:

Public Shared A As Integer
Public Shared B As String
Public Shared C As String
' …

These were used in the process of rendering the hyperlinks. I asked the developer why he'd done this, but he didn't know why. He had just seen the word "Shared" associated with member declarations in the past and thought that he needed to put it there.

He was typically more informed about keywords than this, so telling him that Shared was like "static" in other languages brought instant recognition. In fact he changed the code so that it looked like this (I'm doing this from memory, but I think this is pretty faithful to the original treasure):

' Shared == Static!! Shared variables are static!
Public A As Integer
Public B As String
Public C As String
' …

A Positively Negative Meditation on Sloppy Code

A few years ago, my reaction to encountering code like this was very predictable. You could set your watch to it:

public XmlDocument FooBar()
{
    XmlDocument doc = new XmlDocument();
    doc.LoadXml("<foo/>");
    XmlElement bar1 = doc.CreateElement("bar");
    doc.AppendChild(bar1);
    bar1.SetAttribute("id", "1");
    bar1.SetAttribute("value", "bar1");
    XmlElement bar2 = doc.CreateElement("bar");
    doc.AppendChild(bar2);
    bar2.SetAttribute("id", "2");
    bar2.SetAttribute("value", "bar2");
    // ...
    XmlElement bar30 = doc.CreateElement("bar");
    doc.AppendChild(bar30);
    bar30.SetAttribute("id", "30");
    bar30.SetAttribute("value", "bar30");
    return doc;
}

The problem with that should be obvious to anyone, and—if The Daily WTF is any indication—I think this is a common mistake. Times have changed, however.

These days, if I had to name my single biggest issue in dealing with code written by others I would have to give an example like this:

public Hashtable Batman(Hashtable ht)
{
    // ...
}

The problem here is not as obvious to your average first-year programmer, but I would summarize the difference like this:

  • It’s not well-defined what is going in.
  • It’s not well-defined what happening inside the function.
  • It’s not well-defined what is coming out (and this may vary depending on #1).

While these kinds of problems are often found together, it seems to be possible to find code that avoids one pitfall but not the other.

The main factor in my attitude shift, you could say, would be what I am personally working on. When the first example bothered me the most, I was only responsible for enhancing functionality created by others and/or fixing bugs in code of the same quality. It was easy to cite examples of bugs that would not have occurred—or at least would have been easier to fix—if the cut & paste keys had not been so liberally employed.

I spend most of my time now gluing together components in the large, working on architectural things that many developers will never know or care about, and debugging oddball problems. With that background it’s easy for me to say that a cut-and-paster with a thoughtful interface definition has done a good (or even very good) job.

Lack of functional abstraction doesn’t seem as reprehensible to me as it once did. You can always encapsulate it in some functional abstraction. Many great books have been written in prison, and many great software packages have been put together from pieces of spaghetti code.

The second example (the chaos point with no type safety) is another matter. This portends systemic instability. When I find this with the intention of encapsulating-and-never-speaking-of-it-again, it’s very difficult or impossible to locate all of the dependencies. I will usually cut my losses and start from scratch after encountering a few “function Batmans.”

I admit that this insouciance towards Ctrl+C/Ctrl+V is entirely the byproduct of self-interest. It's not that I think it's a good idea, it's just that I can't muster the energy to get upset about it. If a passionate new programmer were to vocally find fault with it I would wholeheartedly agree.

Finally, This Site Produces Some Results

In my last post, I complained about an obscure Excel crash. Well, this morning the client got back to me saying that he opened up the original workbook (with no workarounds in place), and obviously, got the crash.

However, something was different this time. Dr. Watson showed him a link for more information, which he followed and found a download link for Office 2003 SP2! Released on September 27th! It fixed the issue! Less than a week after I lost a whole day debugging and working around it.

Thanks to Microsoft for monitoring the blogosphere closely and for being so responsive to my issue. Hopefully, the legion of call center workers on The Sub-Continent who refuse to escalate my other premier support case to anyone even remotely familiar with the Excel code base helped in churning out this incredibly timed hotfix.