What's it all about, Alfie?

Yesterday afternoon I had a hiccup on the networks and the NXMachine session I had from my desktop to one of the servers in the data center was disconnected. Unfortunately, attempting to get it back proved fruitless. No matter what I did, it was saying that there was an authentication problem. Yet just 10 mins ago I was connected and doing fine.

Reboot didn't help. I could SSH into the box, but I couldn't get the NXMachine session going. The UnixEng guy tried, but he wasn't all that good at debugging this software, so I had to work on another box for the rest of the day.

This morning I came in ready to try and solve this guy on my own. What I did was recheck everything. Make sure the box where it was working and the non-working box were set up right. I checked the scripts, the files - all seemed like it should work. Then I noticed the file owner in the /usr/NX/home/nx directory. It was owned by userID 999 and not the user nx. Oh... this couldn't have been it...

So I went through the entire /usr/NX directory comparing a working machine to a non-working machine. Every place I saw the userID 999 I did the chown nx and after I cleaned up those ownerships it worked! Sweet!

Lesson learned: check the file ownership and permissions.

This afternoon I started work on the next component of the greek engine project - a list of pointers (instruments) that is thread-safe, and has iterators that are never invalidated. It's the combination there that's really tricky... how to make a list that has many iterators on it - none of which will be invalidated on an isert or removal operation on the list.

Yeah, that took some thinking.

My initial idea is to have a fixed-length list of nodes. Each node has a value, a 'valid' flag, and a spinlock. In order to add to the list, you need to scan the list looking for the first node that is not valid, but who's try_lock() is successful. You can then place the value into the table. Pretty simple, really. The locks don't effect anyone else, and things are pretty smooth.

The iterators are going to be something where I can step through all the valid values and optionally lock on that node to make sure it gets "stepped over" by the other iterators. It should make for just what I'm looking for.

Lots of coding to do, but I think it's all planned out and should work. I just need to actually do it.

This morning I wrote the skeletal InstrumentFactory and InstrumentMap for the Greek Engine to get some of the other guys in the team helping out. These two classes work together to construct and then hold the universe of Instruments that we'll be working with. It's a model I've used in the past, and it really seems to work pretty well. I just need to get working and figure out how to make a thread-safe, lockless, list with iterators so I can run through the stocks in this map for calculation purposes.

No rest for the weary...

Today I spent my own coding time building a client for the Position Service at The Shop. It's a TCP-based service that you can subscribe to and receive updates from. It actually looks to be pretty darn sane - which is a little unusual for the state of things here, but I'm willing to roll with it. The wonderful fact is that I've been working with boost asio enough now to be able to ship up a nice TCP-based client in just a few hours. It's pretty powerful stuff.

Throw in a little thread and memory block pooling and I have a client in very short order. The only problem I had was that a critical part of the functionality could only be tested during trading hours, and I didn't get enough of the code done to test that by 3:00, so I'm going to have to test that tomorrow and see what needs to be finished.

In all, though, a pretty decent day.

Today I needed to tackle the 2-D grid and interpolation in as efficient and re-usable way as possible. In previous attempts, I've used special data structures to hold the data points because the interpolation was handled differently. This time, I wanted to take advantage of templates for the z-value so I could re-use the class for doubles as well as entire packages of greeks. In order to do this, I decided that it'd be better to use boost::unordered_map and have the key be the coordinate value, and the value be the function value. When I needed to handle two dimensions, the outer map values were really just axis/function values, and with a simple spinlock to protect the grid, we were done.

All this coded up pretty easily. We are going to stick with a four-point interpolation scheme so the code had to "locate" the four nearest grid points to any given point, and then allow the caller to ask for the interpolated value anywhere on the grid. It's just a few detail functions, and it worked out pretty nicely. The final point was having a templated function that took the (x,y) points and the z values, and then returned the interpolated value. This would allow me to make one of these for double values, and another for the greeks package.

Because it was completely isolated from the rest of the grid, I could change the interpolation from a simple linear to a Taylor Series at any time, and that's exactly what I have planned for the greek payload. After all, I know what the x- and y-axes are in this space, and I know that within the payload I have the derivatives, several powers worth, and that will make it a lot easier to space these points further apart and get reliable interpolated values.

All in all, I have to say I've enjoyed coding this up. Not everything today has been this fun, but at least this was a good note to end the week on.

It's always nice to start off the day nicely. A nice run, something fun on the computer, maybe a nice breakfast, but today I got all this and a little more - a manager who thinks he can code. But he can't. I've been placed in the position of Technical Lead pf this project, and I have to work within the management style of the team's existing manager. He's a decent guy, I suppose. He's not the kind of guy I'd have over for dinner, but I'm sure he means well, in his own way. But he fancies himself the coder. Maybe he was, in a different environment, but here and now, he's just so-so, and he doesn't approve of my technical management style. So he goes around it - he does whatever he wants, and thinks I'll have to accept it.

He doesn't know me as well as he should.

Well... he thinks he knows me pretty well, but this morning, he's learned that he really doesn't. I told him the work he's done was already done in another class, and over email he tried to convince me it hadn't. I told him it had, and asked him not to write any more code until I told him to. Because I'm putting this together on the fly, and on a very short timeline, there are things I haven't designed, and won't for a few days, but I'll get there, and when I do we'll write the headers and then flesh out the code.

If he's capable, then he might get a header to flesh out, but I've had too much trouble on this project, letting people write headers as they take far too long, and don't get the important ideas captured in the class. So I'm writing the headers, and they are fleshing them out.

This isn't ideal, but it's the best we can do on short-notice. If I had three months to finish this, I'd let them have more involvement in the writing of the headers - which is the fundamental design. But I don't. I'm supposed to be done today. But we won't be done today. We'll be on a rush until this is done. There's just no time to wait for the learning experience. I didn't make the deadline, I'm just trying to get the work done on time.

So I get to start off the day with conflict. It's a drag, really. I try to be nice. I try to be supportive, but if, as happened this morning, the person isn't really interested in listening or being reasonable, well... then there isn't a lot I can do other than be blunt and tell them to just stop coding. They don't like it because they believe themselves to be beyond the need for supervision, which is, of course, part of the problem. So it gets ugly, and I'm the "bad guy", and so it goes.

I'm asked to do an unreasonable job, and take it very seriously. I have to be a bit unreasonable to get the job done, and people get upset. Of course, they get upset at me because they don't see the cause-and-effect of the unreasonable request and my actions. But it's there. They just refuse to see it. They'd rather blame me.

And so it goes...

What a way to start a day.

I know it seems petty, but if you have a really abusive manager or co-worker, it's sometimes really nice to see them shoot themselves in the foot. It doesn't happen all that often, but this morning I was lucky enough to be able to be nice to a really socially challenged manager, and watch him simply show his complete and utter foolishness. He hung himself real good.

It was an email chain, and while I'm always careful what I read and respond to, I can tell when there's someone in the chain that isn't. They ask the same question when it's been answered, they don't answer questions, it's all pretty obvious. But couple that with a person that's really not very nice, and you get an abusive person that tends to show his worst qualities at the most public of times.

And that's just what happened.

I haven't dealt with this guy a lot, and I try not to prejudge folks, but today I learned that he really doesn't listen to other people. Not at all. While he may be right at times, it doesn't excuse the not listening, for today it wasn't about right or wrong, it was about information I was trying to get out of him, and he just never really read the email well enough to understand.

But he sure popped off on me several times. I was nice, and apologized for not making my points clearly, and then highlighted the relevant sections from the email for him to read again. It made him look bad, and that's a good thing, in my book. Maybe a little humility will do him good.

Probably not, but it made me feel a lot better.

There's a very interesting book called The Mythical Man-Month and the crux of it is that there is no such thing as a mon-month. You can't look at a project and add "units" of work and assume that it will linearly scale. It just doesn't work that way. Well, today I had my own reality check with just this proposition.

While I don't have accurate numbers, I'm going to give ballpark estimates to illustrate the point. You have three developers: Steve, Ted, Bill. Steve is the best and can deliver about 1000 lines of debugged code a day. Ted and Bill are junior guys and are in the 100 lines of code a day range. They wrote decent code, but not as good as Steve's, and not nearly as fast.

Give Steve a project that he can finish in a week, that's 5000 lines. It'd take Ted or Bill ten weeks. The "mythical man-month" says that if you add Ted and Bill to Steve's project, it has to get done in less than a week. Yet when you do this, it takes longer than a week. Why?

Because Ted and Bill are pulling Steve away from his work. He's no longer capable of 1000 lines a day - maybe only 500 because he's spending half his time answering questions, re-writing code, checking compiler errors for the two guys that don't know how to perform at his level.

Is this bad? No. Unless you want that project done as quickly as possible. It's the process of Steve imparting some skills to the junior guys. It's great if there's time. But in this example, adding Tim and Bill to Steve's work is going to slow him down to 500 lines a day, but these other two are only adding 100 lines each - so the combination is only 700 lines a day -- a reduction of 30%.

So if you think you're going to speed things up, follow this rule: Never slow down the top performers. Never. It's not the time to teach, it's the time to get things done. If you want to teach, take the time to do it right, but don't put the team on a tight schedule.

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.