What's it all about, Alfie?

I just got done talking to my two teammates about the value of defensive coding. Specifically, that there is value in Java of checking the value returned from every method call - including the JVM's new operator. I'm stunned that these guys believe that it's "silly" to check for things like that. I say, that's the bloody point of checking things in code. Have they not read Code Complete? Have they never really built large, critical systems that simply didn't have the option of failing?

My guess is, the answer is No.

In my code, you'll see a lot of code that looks like this:

  /**
   * This method returns the reference to the BKIRCProtocol that is
   * going to be monitoring the traffic from the IRC Server while we are
   * connected to it. If there is no listener defined at the time this is
   * first called, then create one because we really need to have it.
   */
  public synchronized BKIRCProtocolListener getListener() throws BKException {
    if (_listener == null) {
      _listener = new BKIRCProtocolListener(this);
      if (_listener == null) {
        throw new BKDebugException("BKIRCProtocol.getListener() - no protocol
          listener was present and one could not be created. This is a serious
          Java allocation error and needs to be looked into.");
      }
    }
 
    return _listener;
  }

Where I follow a new with a test for the resultant against null. It's standard coding style for me. When I was at First Chicago, I had the great fortune to work with an incredible group of guys. They were pivotal in having me look at coding as something a group can do as opposed to a series of individuals. In that group, I learned the value of having the code look like one mind wrote it. Debugging and fixing was as easy for one as it was for all. The style wasn't exactly mine, but we agreed on one for the group, and it stuck. It was great.

I have been trying to re-create that kind of experience and to some extent, I've been able to succeed in very limited cases. But I have seen it again. When you look at coding as not your work, but the team's work, you start to see that there's more to it than what you think. You care about the next guy getting the call to fix a problem you might have created. But when you write as a team, it's impossible to tell who wrote it, and that makes debugging vastly easier.

I guess I'm just surprised that I'm talking with developers making six-figures and they are talking about "how often" in the error checking. It's just stunning. You only have to write it once, and then it's always going to be there. That's the "how often" you need to focus on.

Expect more. Build it better than it has to be.

Today Apple announced upgrades to the MacBook Pro line. It's pretty slick. There are a few things that I really like about the machine:

• Core i7 - this will give me single-threaded performance of a 3.33GHz machine and when that's not needed, four cores (2 physical + 2 HT).
• New Graphics with Dynamic Change - no need to change the GPU you want to use in System Preferences and logout/login - the GPU is now automatically chosen based on the load. Plus, it's a faster, better GPU for the OpenCL bits.
• 512GB SSD - this is amazing to me: 512GB and SSD. That means all the space I have now and it's all a lot faster. Amazing.

Of course, it's not cheap, but then again, they never are. They are, however, the best laptops on the market. Amazingly Cool.

Yesterday I was adding a feature to one page in my web app, and I wasn't happy with it at all. It was excessively crowded, and to me clearly looked like a forced fit. Yet, this is just what I was asked to do, and until I really completed it, I couldn't be 100% sure that it'd be such a horrible mess. But it was. Holy Cow! What a mess.

So this morning I decided that I was going to leave that page as-is and add the feature to the web app as a new page - specifically used to show historical data for some portfolios. I know it wasn't what my manager wanted, as he'd "talked" to me trying to understand what I was building. I told him to wait and see, and still he kept at me about trying to understand. I hope I made it clear that I wasn't interested in back-seat designers, but I'm guessing he didn't get the hint at all.

In any case, I decided that I was going to do this, and it didn't matter what he said. I was going to do it right, because I just knew there was a better way to visualize the data. So I didn't stop.

When I got done with the page - heck, I didn't need to get done with it, but just to the main visualization. It was clearly a vastly superior interface for this kind of data. Far cleaner, far clearer. Wonderful. I wish I had a screen capture of the two to compare, but it's not in the cards at this time. So it goes.

What impresses me most about this experience is that I did just what I wanted to do and came out on the other side with something that was vastly superior for the end user. I'm not going to be bullied into making a slap-dash product again.

Today I have been adding in the ability to see more than just a day in my web app using the Google Visualization Annotated Time Line (ATL). The problem is, the ATL is a good time visualization tool, and it's not really producing "good" looking plots for the weekly, monthly, and yearly data. Oh, it works, but the x-axis remains true to the date/time which means that when I show a week, two of the seven days are flat, and very uninteresting. But there's no way to "compress" the "blank" space in time.

The other problems are that some of the data is 'reset' every day - like the P/L. That means that every day it's going to start back at 0, and work it's way up (or down) that day. But in the end, it's going to go back to 0 at the start of the next day. While this is exactly what they want from a business and accounting point of view, it's not leading to very interesting looking graphs as they seem to just "jump up" a little and then hop back down to 0.

For a lot of the datasets, the trading day is about eight hours, which means that the majority of the graph really doesn't have anything "interesting" on it. This is exactly what you'd expect, but it leads to a view that's really not very nice to look at.

So in the end, while it works, and does exactly what I asked it to do, it's not really what I want, nor is it reasonably speedy. It's going through a ton of data, so when looking at the year, it's a good 30 sec to get new data. Not really "zippy", that's for sure.

I'm glad that I got the code to work - it's quite a bit of non-trivial code, but I can't really say that I like the way it looks. It's doing the right thing, but it's not what I think the users are going to want to see when they think "week", "month", and "year".

I've kicked it out to the group and we'll see what everyone has to say. I'm betting that the guy who asked for this is going to have a mixed reaction to it, and write a 42-page opus on what to do next to make it better.

Goody.

I read this little article from the NY Times on Slashdot this morning about how the US DOT is interested in cracking down on the "epidemic" of distracted driving that is cell phone usage in cars:

“It’s time for drivers to act responsibly, put their hands on the wheel and focus on the road,” said Transportation Secretary Ray LaHood, who last year called distracted driving an “epidemic.”

Interesting. While I couldn't find the quote in the NY Times piece that they were going to be cracking down on even the use of hands-free headsets, this little quote makes that seem pretty likely:

Studies have shown that drivers talking on a cellphone face four times the crash risk of someone not talking on a cellphone, and that the risks at least double when a motorist is texting.

Pretty wild stuff. What's needed is something that allows cell phone conversations and keeps people safe. That's a seriously winning combination of technology and someone will make a bundle on it.

This morning I noticed that Cyberduck 3.4.2 was out with a few new localizations and a few little bug fixes. Nice to see. I then tried to verify that my home WebDAV server was working after I upgraded it to Mac OS X 10.6.3 over the weekend. In the past, I've noticed a little configuration updating with significant OS X upgrades, but this time, I'm glad to say, it seems to have left the SSL and WebDAV configurations intact. Nice.

However, what's a little troubling is that I couldn't connect to my SSL/WebDAV server with Cyberduck, but I could with Transmit. Now I can see that in Transmit, I'm using a given password - which is good as the WebDAV password can be (is) different than the login password, but there's no way that's getting sent to the server. I've checked the Keychain and it's not there - not that I can see.

So I'm a little stumped.

Then again, it's possible that it's just not working properly in Cyberduck, as it's clearly working just fine in Transmit. Gotta say... looking a lot better for Transmit.

UPDATE: OK, this is very odd... in the Cyberduck configuration, it I place the path: webdav/ in the More Options, Path field, I get the message that it can't connect to the server. It needs the abs_path. OK... so I tried a ton of things - finally trying: /webdav - BINGO! That got past that point, but then I get the statement that the certificates is not trusted.

So I then try a few things with the Keychain to see if I can fix that up. Nothing seems to work, and in truth, I didn't do a lot. But then I go back and try: /webdav/ and BINGO! Now we have a working WebDAV connection. Cyberduck is not very forgiving on the connection issues. Not forgiving at all.

I'm not the easiest person to work with, this is not news to me. But as long as I've been at my current job, I've been working very hard not to be as blunt as I might wish to be with co-workers. Specifically, co-workers that are doing a really bad job. So imagine my surprise when today I was able to exchange emails with The Smartest Man Alive. TSMA, as I'll call him, is a developer at The Shop and he's got a pretty well deserved reputation for being a prima dona. But hey, he's also TSMA, so it's OK, right?

This morning I got the following email from a fellow developer in my group that was trying to get TSMA's stored procedure to work:

   From: Mary
   Sent: Today
     To: TSMA, Steve, Bob
Subject: RE: lock problem again

Steve said the lock is free now.

Bob looked in the logs and sees the lock acquire error happening 4-5
times a day. TSMA, this sounds like expected behavior, right?

Mary

I had heard about these locking problems yesterday, and had reported to Mary how many times I was seeing them happen. It was a lot. When these locks happen, we're losing data, and that's not good. So I have to give it to Mary for sending this back to TSMA.

His response was a little surprising to me:

   From: TSMA
   Sent: A Little Later
     To: Mary, Steve, Bob
Subject: RE: lock problem again

my code retries (up to several times with a short sleep in betwen)
on one of these deadlocks and I have not yet seen a case where all
retries fail -- so honestly do not know how often the deadlock hav
happened.  But a few times a day does not sound unacceptable to me.

TSMA

(I've left the typos in the emails just to remain honest to the communication)

And here's where I have to step in. I am able to separate myself from a really bad job - so long as it's not brought up in front of my face. You want to do a crummy job? Fine. Just don't expect me to depend on it, and don't do it in front of me. If I let it slide, then I look like I knew it was happening and did nothing to stop it. That's not OK with me.

So I wrote back:

   From: Bob
   Sent: A Little Later
     To: TSMA, Mary, Steve
Subject: RE: lock problem again

TSMA,
  While I don’t claim to know the details of this project, or the
database involved, I would think that any design that allows a
failure to occur through normal usage is a bad design.
  Deadlocks are something that needs to exist in database usage
to keep the database running in those rare conditions that multiple
locks are involved in a single query or transaction.
  When some process or request needs to ensure some kind of data
integrity, there are many perfectly acceptable ways to achieve this
without the process failing – multiple times in a day.
  Does your car fail to start multiple times and day in the course
of regular usage?
  Does your computer fail? Your phone? Would it be acceptable to
you if they did?
  I think you get my point.
  While it’s not my database, the idea that this kind of level of
service is justified because it only happens a couple of times in
a day is really a stretch, don’t you think?
  Let’s follow our CEO’s words: “Raise the bar.” Be better than
this.

      Bob

This was, of source, a huge mistake, and I clearly didn't realize that I was talking to The Smartest Man Alive, after all. His response was quick and decisive:

   From: TSMA
   Sent: Right Away
     To: Mary, Steve, Bob
Subject: RE: lock problem again

Bob,
You would have done much better if you stopped with the first part
of your first sentence since that's the only piece of your email
that's shows any understanding.  The deadlock in question is the
one the sp announces it is preventing.
 
Save your advice to cases where you actually first bother to ask
questions before making grandiose statements.

TSMA

and then just a minute later:

   From: TSMA
   Sent: One Minute Later
     To: Mary, Steve, Bob
Subject: RE: lock problem again

and by the way Bob, get rid of the patrionizing tone, although
*you* may not be better than this.

Well... that certainly showed me, didn't it?

I sat totally shocked by this response. I'll admit, he's a prima dona, but really... do we need to have the attitude? Maybe he felt I was over the top. Maybe, to him, I was. But when I've talked to several people about - including the Senior Partners in the firm, they think that the idea that a critical risk system fails 4 or 5 times a day is anything but OK.

The Shop is filled with people that have no accountability - or such limited accountability that they can all but break the law and get away with it. The problem isn't in the individual, it's in the organization. If the organization did, in fact, hire The Smartest Man Alive, then great for us. But if the cost is that he's incapable of delivering a reliable product, and when pressed on the issue insults, well... then maybe it's too high a price to pay.

It's not my Shop, so it's not my decision. And I have no illusions about the fact that there are literally dozens of these guys at this place. Each one associated with a group of traders that protect them so that they can nearly get away with murder.

The real long-term cost is that people don't want to work with this kind of individual, and that means that should something happen to him, the organization is at a real loss. There are also people like me that see this as the prime reason to avoid this person and, if necessary, duplicate his work because he's shown himself to be incapable of creating solid, reliable products with a decent support arrangement.

But I can sleep easier tonight knowing that I exchanged emails with The Smartest Man Alive... well... at least the most arrogant developer in The Shop.

Today I spent a little time looking at how to make my existing web app able to view data historically. The first cut through a lot of these pages has been to show the data for today and then not worry so much about showing it for the previous week or month. Well... I wanted to take a swing at that, and I was pretty happy with the results.

Once I figured out which database the data was in, and I did that by looking at the supplied date (thank goodness I had that in the query), it was a simple matter of direction: if it's historical data, hit the back-end database, if it's current data, hit the in-memory database.

Couldn't be any simpler than that.

Now there's still the issue of some of the conversion factors - those aren't currently loaded historically, and then there's the goal to have the pages span more than a day - like a week, or a month, or a year... but I'll get to those starting tomorrow. It's enough for me to be happy about the progress I made on all these pages in a very short amount of time.

Nice job.

Today I had one more in a very long series of conversations with a manager that seems to want to understand the technical details, but I suspect really only wants to be able to appear to understand them. Basically, he wants to write a good email, and appear to really have a complete and deep understanding of the technical issues surrounding the problem. While I admire his desire, the exercise really comes off as The Great Pretender.

He's not technically trained, and while he may have some Excel "programming" or Matlab experience, it's not the same as really writing a system. Which means he believes he can understand the ins and outs of all technical decisions, and to a point, he probably can. But there has to come a point when he accepts his limitations on understanding and trusts those people he has asked for their opinions.

For example, I shouldn't ask the car dealer about the specifics of the on-board computer with regards to the spark advance during high-torque intervals when the humidity is greater than 90%. It's certainly a technical question, but the real issue for me, as a driver, is Will the car drive as I expect it to? I don't need to know every single detail, but I'm sure there are automotive engineers that do know all this, and good for them.

I'm not arrogant enough to think my opinion is essential, but if you ask for it, and then try to argue with me about it because you believe you have the salient technical facts, then it's a bit... oh... let's call it "excessive". Let's say he's asking about how to build a database. Specifically, what hardware should he buy to get what he wants? In my opinion, he needs to ask what storage he needs, then balance that with the costs of a few different alternatives. In the end, he shouldn't be grilling people about the difference between 1GB drives and 2GB drives - that's a detail that he really doesn't need to be involved in because his area of expertise and responsibility is not which drive to pick - it's the basics of balancing the technical needs with the business needs.

This happens at least a few times every week.

Today it was an email about the packet contents Hemlock receives from it's satellite processes. He asked if it was XML? Nope, it's tab-delimited ASCII. He then asks about the XML he's seen on my monitor. Yes... that's XML, but that's coming out of Hemlock, not going in? OK, so what's going in, a text file? No... it's tab-delimited ASCII data stream. And so on...

I'm not trying to make it difficult, I started saying "it's text", but he kept digging, knowing that wouldn't sound technical enough. And while I admire his desire to use the proper terminology, if it were only that, he'd have written down ""tab-delimited ASCII" the first time I told him. Not wait for me to explain away his confusion and then write it.

If you want an answer, ask. But don't then argue about it. Just take it and go. Because i know he's not using this as a traditional classroom situation where he's not going to ask again. It's like this several times on each point.

In the end, I'm just annoyed.

I remember my Econ class at Purdue - the professor used this quote:

Don't try to teach a pig to sing, it'll only frustrate you and annoy the pig.

and that's exactly what I feel I"m doing with this manager. Very frustrating.

This morning I noticed that the Flash 10.1 Release Candidate was out - 10.1.53.7. While I typically use ClickToFlash to not view Flash in Safari (my primary browser), when I have to use it, I want to make sure that it's the best and latest version of Flash. This branch of Flash is supposed to be much better performing on Mac OS X, and it's about time - the vast majority of creative professionals are on Mac, why hasn't Adobe made Flash a top-notch player on the Mac?

Well... it's here, and for all I need, it'll do nicely.