No Whining! (...at least not today...)

Rather than complain about something, today I want to contribute. I have been working on some very simple command lookup programs in various languages. I've finished most of them (one more to come - the C++ version). They are in Google Code at http://code.google.com/p/dead-simple-command-lookups/. Note that I've put the files into the download section as well as under Subversion for those that don't want to bother with getting a Subversion client running.

Cell Phones Are Still a Compromise

I have a cellphone but it's off most of the time. I've given out the number to very few people, and they know that I keep the phone off most of the time. Since I don't have call blocking enabled (that I know of!) anyone I call can grab my number. Since I don't, however, call that many people, I don't worry about who they are.

A number of months ago I interviewed at Google. I didn't get the job (sigh) but that's bits into the bucket. One of the pieces of information that came across in one of the emails (from their recruiter) was that they preferred that their interviewees NOT use cell phones during the phone screens.

This intrigued me. I'm not sure whether this is because cell phone networks in some countries aren't up to snuff or for some other reason(s). I do know from my own personal experience that about half the cell phone calls I make have dropouts or clarity problems, even in "civilized" places like the San Francisco Bay Area. Which actually is the primary reason I don't turn my cell phone on unless absolutely necessary.

JavaScript Strikes Again

In a recent job interview, I was asked how does one detect (in a JavaScript function) whether a parameter actually had a value passed to it. It's been a long time since I've done any JavaScript, so I answered that I assumed there was a way to test for "null". The interviewer said that I had the appropriate concept, but the actual language keyword to test against was "undefined". We then had a brief discussion about null versus undefined, but I wanted to find out more.

Google turned up this page which has some very concise and useful examples. I was not amused, however, to read that testing for null will return true regardless of whether the value is actually null or undefined. I would hope that testing for undefined doesn't return true for null, and I hope to have time to test this sometime in the future. This brought me back to the first time I realized that JavaScript didn't (in previous incarnations, anyway) syntax check code that was never executed. I'm used to that happening for shell script, but it brought me up short for a language that actually seemed to be used in many shipping products.

I guess one works with what one is given, but it doesn't make me any more confident in JavaScript as a robust language.

Today's Formatting Hobgoblin

One of the little things that bothers me about some of the code I work with is the variation in handling of the "if" statement. In this code an "if" with a single statement in the "if" block (and no "else" block) will end up on one line:

if (condition) do_something_else();

I find this interrupts my reading of the code. I realize that putting brackets around the statement in the "if" block and putting the statement on its own line will add two lines to the code. I find, however, the consistency of formatting makes the code easier to read (for me, anyway).

This may be a foolish consistency or not. I looked back to my favorite coding standard for support. The Linux kernel coding style says "Don't put multiple statements on a single line unless you have something to hide." This doesn't mention brackets, but that follows from other standards.

At least I'm not the only voice crying in the wilderness...

Copy/Paste Considered Harmful

When I first started coding years ago, it was in a very early version of Basic that ran on the timesharing computer at Dartmouth. I had no formal training and committed many of the sins of self-taught programmers, including programming by copy/paste. After a few times of having to fix bugs in multiple places I started learning about functions in Basic so I could stop that nonsense. I also became aware of how messy it was to add new features in copied code.

At this point in my career I am more aware of this problem, and tend (when I see it in existing code) to refactor before going on with my planned task(s). If there are automated QA tests with the appropriate coverage I assume they will catch problems. If not, I construct a few automated tests of my own to increase my confidence that the refactoring didn't change any existing behavior.

I was talking with a co-worker a few weeks ago about coding practices, and the topic of copy/paste came up. I went into my usual rant/sermon about it, only to find out that he actually had a professor who promoted copy/paste as a method of "code reuse." I don't know where my co-worker went to school, or what this professor had a degree in, but it took me aback to hear this.

Now there are a few times where copy/paste is appropriate. For example, if we are late in the QA cycle and about to release a product and find a real show-stopper of a bug. After analyzing the bug and determing the cause and the fix, we realize that it is deep in some code that is called from many other places. Given the time frame, we're not able to test all those places to the level of quality that we would like. In this case, I have occasionally done some copy/paste to make sure that the side effects of my change are as minimal as possible. I always, however, put a TODO (or TBD, or other cleanup marker, depending on the coding standards of the company I'm at) into the copied code with a reference back to the source of the copied code. This then goes as a task at the top of my cleanup list for the beginning of the next development cycle.

I don't see how to produce long-lasting quality code without doing this.

[Minor pop quiz: where does the title of this post come from?]

Setting Expectations

I was talking with my young niece a few days ago about getting shots. She told me she really hated them. I then told her a story about my brother who had always had a deathly fear of shots. At one point he and I were talking about this (as children), and it came up that he had always thought that when the doctor pushed the plunger in, it was making the needle go further into his arm. He said he was really frightened that it would go into his bone.

At that point my niece's eyes got big and she said, "You mean, it doesn't push the needle further in?"

I was intrigued that she had the same mis-information as my brother. It made me think of how hard I work to give correct information in order to set expectations. I feel that one characteristic of good engineering is to set expectations correctly. This may sometimes go against the wishes and hopes of the marketing and sales folks, but it has to be done. I do, however, feel that (in the long run) setting expectations correctly works for both me as a producer of software and my customers as consumers of software. By "customer" here I mean both internal (e.g., within the company) and external (e.g., paying) customers.

If I set expectations too high and don't meet them, my credibility is damaged, and people have a long memory for failure.

Lowest Common Denominator Wins This One

Today I came across this article from Component Developer Magazine about ODBC. I was especially amused (and bemused) by this quote:

At the time of its release, the SQL Server team at Microsoft believed OLE DB would supersede ODBC. This is not longer the case and ODBC's future is completely secure. ODBC is more widely used that OLE DB and it is better suited to some key scenarios that I will discuss later in this article.

I was originally planning to title this post "Old APIs Never Die, And They Never Fade Away Either." The message here, though, seems to indicate (if by omission only) that OLE DB's future is not completely secure. Or maybe I'm just trying to dig too far into the sub-text.

In any case, I believe this is a case where ODBC (as clumsy as some think it is) has won precisely because it is low level, focused on one task, and does not have a lot of proprietary technology that needs to be duplicated across platforms. While ODBC on non-Windows platforms such as Solaris and Linux still has a lot of rough edges, it's generally usable except for the occasional configuration nightmare.

I wonder, on the other hand, what will happen with efforts such as Mono, which are attempting to duplicate a much higher level of functionality and more compilicated interface. As Wikipedia says (today, anyway):

The Microsoft compatibility stack provides a pathway for porting Windows .NET applications to Linux. This group of components include ADO.NET, ASP.NET, and Windows.Forms, among others. As these components are not covered by ECMA standards, some of them remain subject to patent fears and concerns.

Sometimes one's eyes are bigger than one's stomach.