What's it all about, Alfie?

I've come to some significant decisions about the folks I'm working with. It's important to know what you can count on help with, and what you're going to have to slug through yourself. For example, I know that Liza is a great cook and Mom, but to expect her to fix a computer is not really where her strengths lie, and it's not something I can rely on her to help out with.

Same goes with the guys on the team. I'm coming to some really important realizations about this. It takes a different kind of developer to write good designs. I can do it pretty well. I'm working with some guys that are really struggling to come out with solid designs. Some really just aren't even close - yet.

Maybe they'll get there. Maybe soon. But today - nope. Asking them to write headers is frustrating to them as they struggle with the task and then turn in something that I have to rip to shreds to get right. It's not personal, but it is. We need good designs, and if it's not something you can do, and you don't take yourself out of the mix, then you're going to get your feelings a little hurt.

Face it. If I played golf with Tiger Woods, I'd be doing a lot of walking. That's just going to be demoralizing after a while. I'm no pro, but I love the game.

So I'm going to have to not make these assignments. I'm going to have to be the one that builds the skeleton and then lets them flesh it out. In some cases, I'm going to have to nearly complete the class implementation and let them finish. It's a slam dunk then, and they'll get a little confidence. Maybe it'll help.

I just know I can't let them slow me down more.

This morning I saw that Google Chrome dev 12.0.733.0 was out and the release notes say only that the release focused on stability and UI tweaks. I noticed they fixed the centering of the page title in the tab which used to be left-justified, then it switched to centered, now it's back to left-justified. I'm sure there are other things like this, and that's OK, it's a pretty stable browser.

While it may be like rearranging deck chairs on the Titanic, I'm feeling that my advice to myself is starting to have the desired effect. I'm getting things done, worrying less, and realizing that things might not get done, but they'll get closer to done.

May be a minor point, and it all might be rationalization, but it's helping me and things are moving along. That's better than all the worry. Way better.

Today was spent doing a lot of fleshing out of C++ classes. It's getting a lot closer, and we might actually have something to test by the end of the week. I'm as shocked as anyone because there's still a lot to do, but if we keep making good progress, it's possible to have something that's running in development - very roughly by the end of the week.

Wow.

Today I fought a nasty C++ inheritance problem. It's not that I wasn't expecting some problems, I just didn't expect the kind of problems I ran into. The design is a pretty standard one for the finance industry for tradable instruments:

There are clearly two diamond problems in this model: the first is ending on the Future and going back to the Instrument, and the second is ending on the Stock and going back to the Underlying and Instrument.

Interestingly enough, I was able to make the blue inheritances virtual and it all compiled. But when I tried to run it, I got constructor problems in the Instrument class that I should not have gotten. Clearly, there was something more going on here, and I had to be more explicit.

Alternatively, I could look at the design and realize a few facts:

• The only Futurable Instrument is a Stock - seems odd, but with this model, that's all that can have futures on it. We can certainly throw indexes and other instruments in the "stock" class, or even further subclass it, but it's a nice simplification.
• All Underlyings are Optionable - again, because of the way the design is laid out, it's clear that the Optionable feature can be incorporated into the Underlying without limiting the model.

The only problem with these two simplifications is that I can't have something that is Futurable and not Optionable. As I think about what I've done in the past, I think this is a fairly good bet.

With this, the design becomes much simpler:

This has only the one diamond problem, and it's easily solved with the virtual inheritances shown in blue. It's also a lot simpler to see and understand, and there are no "placeholder classes" that simply have to be there for classification purposes. I'm not sure I like this a lot more, but it's cleaner and it'll work better, and has fewer moving parts, so on the whole, I like it more.

It's now 5 days before I'm supposed to be delivering a working greek engine to QA at The Shop, and while there's still a slim possibility that it'll work, I have so many doubts about things that aren't done it's hard to really think it's likely. Then again, getting even close is a victory in my book - after all, I was only given 4 weeks to do this, and I would have bet it would have taken twice that at a minimum.

Still... I've got five days, so let's make the most of them...

Today has been another long day in fleshing out the implementations of the headers a co-worker has put together for the greek engine. He's had the most experience with the model in use, and the gotchas with the data going into said model, so it makes sense for him to define the headers to a decent point, and then several people can take it from there.

It's not particularly exciting work, but it needs to get done and seeing as how we're a week away from "being done" (so the target says), there's no time to get attitudes about what kind of jobs there are to do - you just do everything you can to move the project forward.

This morning I've come across a real possible good use for a C++ IDE - renaming a namespace in all the places it exists. I realized that when I had the namespace AppKit in another project and wanted to use it in the greek engine project, I couldn't have eng::AppKit because the compiler couldn't tell what to do with:

  AppKit::Message msg;

Is that AppKit on it's own, or in the context of the eng namespace? I knew which one it was, but there wasn't any way I could fine to make the compiler understand that fact.

Also, I knew that the namespace was badly named. I just didn't understand how widely these things would be used. My fault. So I tore into the code with Vim. There's lots to like there, but doing a massive change like this is just not all that easy. It's not hard, it just takes time.

If an IDE could do that, I might have reached for it. But I didn't know one, so I toughed it out.

This afternoon I got the combined pricing feed for the greek engine working. It's not that hard - just a combination of an existing UDP exchange feed and a receiver of the legacy data with a little NBBO engine thrown in to generate the NBBO quotes for these options. It's nothing that amazing, but it needed to be put together as a unit so that it's a lot easier to use than glueing all those pieces together in the greek engine.

Not glamorous, but it's got to be done.

Another late night trying to get what Joseph calls my Impossible Project done on time. I've finally been able to let the Broker sit for a while, and I'm on to getting the database abstraction layer for the static data we'll need in the greek engine working. I've got a good start on it, and SQLAPI++ really helps, but I wasn't able to really get it nailed down before I had to run for the train.

It's getting a little old - these sprints for the train. But hey... it's part of the job these days. I know it's a nearly impossible timeline, but it's what they've asked for, and I'll do my best to deliver it to them as they asked. That's the deal we all make in a business.

I've got about another hour left on this guy and then my first database table will be done and I can hand it off to someone else for them to work in all the other tables that need to be included in the interface. Once I have all this stabilized, I'll work with the static data vendor group and see about converting these into more generally usable Broker-based data services.

Just for right now, it's enough to get them loaded from the database. We can get the rest done later.