Tag: coding

Programming Fashion Faux-Pas

We’re releasing a new version of our code today so the last week’s basically been a free-for-all as far as fixing bugs and implementing enhancements. I had to push some additional Swaption data onto TIBCO for Blackrock to consume. So I had the pleasure of modifying an interface I’ve never worked on before. So I come across this:

if (product instanceof Swap) {
    ...
} else if (product instanceof TotalReturnSwap) {
    ...
} else if (product instanceof CDSABSIndex) {
    ...
}

Dude, are you kidding me? You ever heard of an interface? I think that right there tells me whether or not the person who wrote this code is a seasoned developer with good refactoring skills. I should remember to use that as an interview question. Frankly I wouldn’t hire a guy who codes like that…. It shows a complete lack of programming fashion sense.

Work’s been keeping me quite busy lately, actually. We are finally going live with CDS on ABX next week and I’m pretty pleased since I did pretty much 95% of the development for that. I got to get very intimate with the various credit events that can occur and how they should be handled. Actually Calypso’s not quite up to par in how it models CDS on ABX, at least as far as accounting is concerned. For accounting to get what it wants, a separate transfer needs to be created for each individual credit event. So if MarkIT says on a given month that ABX.HE.BBB-.06-1 has got an interest shortfall of 59.2, an interest reimbursement of 12.5, and a fixed correction of 15.1, Calypso needs to generate 3 individual transfers. As of 8.0.3, Calypso doesn’t even handle corrections at all. (Maybe they fixed that in 9.0?) Of course, the individual transfers can and should be netted together, but each one should generate its own transfer type and, further downstream, its own posting.

Anyway, it was interesting making this enhancement and seeing it trickle all the way down to Peoplesoft.

Dreaming in Code

I’ve just recently purchased a new book, Dreaming in Code, by Scott Rosenberg.

It’s a good read, so far, but I’m only on page 100 or so, so I got a ways to go. Still, I’ve got to chime in right now because I’ve heard and/or read this before and I think it’s bullshit:

Here, once more, was the archetypal dilemma of software reuse. Build or borrow? Virtually every software project sooner or later arrives at this fork in the road. (The full phrase traditionally is “Build, buy, or borrow?” From a technical perspective, though, “buy” and “borrow” are similar, the commercial and open source sides of the same coin.)

Look, I don’t give a damn if you’re the most productive developer or architect in the universe, if you have a solution that fits your needs but perhaps only to 80% and you ain’t buying or borrowing, then you really shouldn’t be in charge of the project. Do yourself and your employer (or client, as the case may be) and focus on technology and let somebody do project management because you suck at it.

Bottom line is: write an interface. Then have the implementation of this interface be a simple adapter to some borrowed or purchased code. If you have time to make it better in the future, then plug in a new implementation. If you rewrite because you ain’t getting that last 20%, then you’re a fool. If you’re at this fork in the road, realize that you currently have 0%, and that you can probably crank out an adapter within a couple of days. 80% of the desired functionality within a few man/days. You have to be smoking something if you don’t follow that path!

Yes, I’m fairly extreme in my views on this, but I’ve found that I’m always right when it comes to this issue, too.

Note to Self: Use session token as argument across all your APIs.

If you’re gonna be running code on any kind of multithreaded environment, a service layer of any kind, whatever… In other words, unless you’re actually running on the GUI and you’re actually dealing with event-driven development… please please please add a session token as an argument to every method call in your API.

You probably will think: “Why? I don’t need it.” But if and when you do, it might be too late… because you might be live at several clients, and you may not be able to change the API at that point in time, or you have to be backward compatible, right? Well, if you ever plan on having two-phase commit, or horizontal access permissions, whatever… you better have some kind of session token that allows you to retrieve your “context.” If you don’t have that, you’ll hack it…. oooohhhh, you’ll hack it real good, because you won’t have a choice. But you know what? If you ever want a clean fix: you’re shit out of luck!