My new office

Yesterday, my wife asked if I wanted to come with her to pick up our son that was spending the day at my parents. I asked her what time and she said that she'd leave around 4pm. Hmmm, I had a 4 pm meeting. I said "sure", but she'd have to drive. 4 pm came around, I got on my phone call, turned on my Sprint MiFi, switched my Mac over to the MiFi's network and was all set.

I hopped in the car, put the MiFi on the dash and my wife drove. The hard part was seeing my screen, so I had to put a jacket over the screen.

No one was the wiser about my mobile office! We didn't encounter any dead cell spots, so the call went flawlessly and I was connected for the entire 30 minute or so ride.

I've had a MiFi for about a year, but for some reason I didn't use it much. Now that I'm paying for my own service, I feel compelled to use it to its fullest.

Leaving logging statements in production code

I've written in the past about how I think that leaving logging code in production or release builds is bad practice. While I have no objections to being able to turn debug logging on or off to help troubleshoot problems in the field, it shouldn't be on by default. Recently I've read conflicting views about leaving NSLog statements in code. One really good solution is:


#ifdef DEBUG_MODE
#define DebugLog( s, ... ) NSLog( @"%s %@:(%d) %@", __PRETTY_FUNCTION__,\
[[NSString stringWithUTF8String:__FILE__] lastPathComponent], __LINE__,\
[NSString stringWithFormat:(s), ##__VA_ARGS__] )
#else
#define DebugLog( s, ... )
#endif

(I've modified the solution a little.)

Then in Xcode's build settings, add a preprocessor macro for DEBUG_MODE. Presto, NSLog statements never make it into shipping code. If you need to turn the logging on and off, I like to write the statements out to a file so that they don't pollute Console and it makes it easier for users to send me logs. Furthermore, I've seen NSLog cause crashes because the developer passed the wrong arguments or did something like NSLog(@"test: %d, self). This type of bug should be fixed, but using the above logging would prevent the crash in production code.

Tenets of software development

Lately I've been talking to people about some development projects and I keep repeating my 2 tenets of software development. The first is from Brian Hall of Mark/Space. He used to say

Shipping is a feature.

While this sounds quite simple in nature, it's pretty important to any product. Not only is shipping a feature, I think it is the number 1 feature. My second tenet is something that I came up with when more and more features were added to a project and QA kept finding issues.

Software is never done; it's just shipped.

Now you're probably saying that these are either obvious or just plain idiotic. Anyone that has done software development for anything length of time has to agree with the second. How many bug fix releases have you done? I may strive to be a perfectionist, but I'm also a realist. You can spend forever making software perfect, but you'll never reach the end.

It's important, in my opinion, for anyone in a software project to be on the same page with these tenets. Without these, you can't ship a product which means you can't make money. There aren't that many companies that I know of that can survive without shipping products and making money (OK, maybe there are companies that only do government contracts and keep taking money without shipping something that works.)

Doing what you love to do

When I was in college, I had no idea what I was going to do. I was in a general engineering program at Harvey Mudd College which was going to prepare me to be a "general engineer". Would a company hire me when I didn't have a speciality? I had no idea and really didn't think about it much. During the winter break of my junior year, I wrote a program called NotifyMail which you could consider "push notification" to alert me of new email. Way back then I was addicted to email and wanted to know instantly when I had email. This was the turning point in defining my career.

For the next 14 years, I wrote a lot of software. I wrote so much code that engineers called me "Dash" from the Incredibles! I lost track of the number of products I worked on, but do have a collection of product boxes and brochures on shelves in my office. 18 months ago, I was tired of writing code, so I accepted my current position where I'd write very little, if any, code, but would do more R&D as well as run IT for a small company.

In my spare time for the last 6 months or so, I've been working on a coding project that really got me to think about what I love to do. It turns out that I love to write code. There is something about the challenge of writing code as well as the freedom in writing code that really keeps me going. Sometimes I get obsessed with writing code so much that I can't sleep trying to solve a problem. Also, being able to say "yeah, I wrote that" and getting feedback from users is pretty cool.

After much personal reflection, I came to the conclusion that I needed to go back to writing code and get out of the world of IT. Last week I tendered my resignation and I'll soon be self-employed again doing contract software development focusing on Macintosh and iPhone/iPad applications. This change, of course, does not come lightly, but I believe it is the right move.

If you have a need for a highly talented (and modest :-)) software engineer, please let me know.