What's it all about, Alfie?

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.

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 has started out exceptionally stressful. I've got a few guys helping me that are not doing so well, and some don't get the urgency of the impending deadline. It's all building up to a ton of stress and I'm starting to be a touch sharp with people. After all, if we're supposed to be done in four days, why are you asking me about a point that should have been worked out a long time ago?

It was getting pretty out of hand.

Then I realized that I wasn't taking my own advice. Specifically, that advice I gave my daughter about her test anxiety. "Don't worry about the grade", I said. "Focus on the knowledge, and the tests will take care of themselves."

Good advice, in my book. But I wasn't listening to it. I wasn't listening at all.

I've been letting this arbitrary deadline I didn't agree to get to me. I'm working 12 and 13 hour days and it's been a nasty couple of weeks. I've resented having to slow down to help people. I've resented the slower people in the group hassling me about giving them work. I know they mean well, but really? I work four times faster than you do. Giving work to you is slowing me down - even if you never ask a question.

But that's not really the point, is it?

Isn't it about trying my best to bring these people along? Helping them see how they can be better at their craft? I think that's the point.

I know there's no way I can't be seen as giving it my best.

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.