Tag: books

Traders, Guns, and Money

I’m wrapping up a truly enjoyable read, Traders, Guns, & Money. The book talks about the going abouts in the world of financial derivatives and it’s a fun read. I’ve even managed to actually learn a thing or two about what all the greek symbols in Financial engineering actually mean. In other words, it’s pretty accessible as well.

In light of that book, I chuckled when reading this quote today by Richard Marin, Chief Executive of Bear Stearns Asset Management:

“We have brought in additional resources with expertise in these asset classes to facilitate the orderly deleveraging process,” said he, speaking of an ailing fund with $1.2 billion in debt.

Orderly deleveraging?!? It’s way up there with collateral damage and corporate restructuring as far as rhetoric is concerned, ain’t it?

Kurt Vonnegut RIP

“When a Tralfamadorian sees a corpse, all he thinks is that the dead person is in a bad condition in that particular moment, but that the same person is just fine in plenty of other moments. Now, when I myself hear that somebody is dead, I simply shrug and say what the Tralfamadorians say about dead people, which is ‘So it goes’.”

–Slaughterhouse Five–

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.