Thursday, November 3, 2005

You Aren't Gonna Need It - Or Are You?

A coworker recently pointed me at this page from the C2 Extreme Programming Wiki.  The basic theory is that, if you find code that isn't being used, delete it.  That is fair enough.  The controversy comes when the code in question is potentially useful in the future.  What then do you do?  The XP advocates on C2 say you should delete that as well.  I don't agree.  If the code in question is potentially useful in the future, I suggest commenting it out (most likely using #if 0).  The arguments against leaving the code in generally revolve around confusing someone.  They might run into the code and try to understand it only to figure out later that it isn't called.  They might be searching the code and  run across it.  There is also an argument that the code will affect compilation times.  If you comment out the code, none of these apply.  The response is often why not just delete the code and if someone really needs it, they can go back in the source control system and retrieve it.  In theory, they can.  In practice, they can't.  I haven't run across a source control system that allows for efficient temporal searching.  Without that, the only way to know that the code exists is to remember that it does.  Not only that, but you also have to remember when it existed.  Somehow, I think that is unlikely to happen very often.  This leads us then to Steve's rules for retaining dead code.  Retain dead code iff:


1)  It does something that will potentially be useful in this area of the code later.  An example might be a slow c-based algorithm for something that is now optimized in assembly.  Someday you may have to port to a new system and you'll want that reference code.


2)  It is not causing you problems.  If this code starts causing problems, get rid of it.


3)  The code works.  If you know it is broken, get rid of it.


This also leads to a feature request for authors of code editors:  Please color code the code between #if 0 and #endif blocks as a comment.

Tuesday, October 25, 2005

Objective Statements - Do You Need One?

   I've been doing a lot of resume screening lately so I thought I'd write up a few of my thoughts.  Ever since my early days as a hiring manager I've told people not to include an objective statement on their resumes.  More often than not, it is worthless.  Usually it equates to "I want a job."  Well, yes.  I could infer that from the fact that you submitted the resume.  Lately I've had some change in my thinking.  I still find most objective statements useless but a well-crafted one can be useful in the right circumstances.


   What are the right circumstances?  The only time I can envision an objective statement being useful is when you are submitting your resume into a large pool.  If you are submitting directly to the hiring manager, it won't tell him/her anything the presence of your resume does not.  Don't waste the space.  If, on the other hand, you are submitting to a large pool such as Dice or Monster or a large company like Microsoft where many hiring managers will be looking at your resume for disparate positions.


   What should be in the objective statement?  Something like, "To obtain a challenging position in the field of software the utilizes my skills" isn't too helpful.  Don't try to sell yourself via your objective statement.  It isn't a mini cover letter.  It should be a clear statement about what sort of job you are looking for.  "A full time position as a senior software developer" is probably all you need.  If there are more specifics--say you are interested in video--make that clear here too.  "To obtain a position as a program manager in the field of digital video." is probably good.  I think there are two main things you are trying to convey here: 


1)  What class of job are you looking for?  Management?  Development?  Testing?  Program Management?  Architect?


2)  Any specific areas you want to focus on.  Know that if you put down specific areas, it will probably cause you to be overlooked for other jobs.  Saying you want to work on telecommunications means you probably won't be tapped for a job working on video editing.  Make sure you are okay with that.  Generally, I would suggest only doing this if you are really passionate or really experienced in a particular area.

Monday, October 17, 2005

MSN Search Getting Better

   As a good corporate citizen I began trying MSN Search several months ago with the initial release.  At first it was pretty painful.  I would search on MSN, not find what I wanted, then switch over to Google.  Recently, however, I have found that I almost never resort to using Google.  MSN Search is finding what I'm looking for.  In fact, I have noticed several instances of MSN Search being better than Google.  First, MSN seems to have more current results than Google.  Several times lately I have searched for something current and found results on MSN when Google still has none.  A recent example was my last post.  This showed up on MSN just hours after I posted it.  Google took until the next day.  Second, MSN is sometimes giving the more relevant links first.  Let's go back to my last post.  If you search for "Some Perspective On Vista" on Google, my blog will be the 4th link.  The first 3 are pages that link to my blog.  On MSN Search, my blog entry is first, followed by all of the pages that quote it.  In my mind at least, the original source should always be ranked above something quoting it.


Update 10/19/05 - Sigh.  Google is indexing this article now but MSN Search is not.  For what it's worth, Yahoo doesn't have it yet either. 

Friday, October 14, 2005

Some Perspective On Vista

   It's been quite a while since Microsoft released a new operating system.  Windows XP was the last consumer OS to ship and that was 4 years ago.  By the time Vista ships, it will have been 5 years.  There are a lot of consequences of such a long release cycle but the one I want to speak about is perspective.  Rather, the lack of perspective.  Most people today watching Vista come along have no perspective about what a new OS is like before it ships.  When XP was being built, the world was less connected.  There were no blogs.  There were far fewer web sites dedicated to rumors and leaks.  The consequence of this is that most people didn't see what the OS really looked like until it launched.  Those that did tended to read about it in magazines with long lead times and carefully scripted presentations.  Today, the public gets to see a much more raw version of the development process.   Another consequence is that even here inside Microsoft, many fewer people have shipped an OS.  Why does this matter?  I have seen a lot of people reacting to early releases of Vista in a negative light.  It is too slow or it doesn't look different enough or it is buggy.  There are also a lot of positive reactions but those are not the aim of my essay. 


   People who react negatively don't realize that this is always what an OS looks like before it ships.  Think of building a new OS a lot like cleaning a messy room.  The first thing that always happens (at least when I clean a room) is that it gets even messier.  I start organizing things by taking them out of their places and spreading them out.  Before I know it, every surface including the bed and the floors has piles of stuff on it.  If I stopped at this point, the room would be worse than it started.  After sorting everything into piles, I can then put it away neatly and more organized than before.  The result is a much cleaner room.  An OS is similar.  The first thing you do is start removing old, working parts and replacing them with new parts.  These new parts start off less powerful and less stable than the parts they are replacing and only over time become more powerful.  A good example of this is in the world of audio.  The team I work on helped to produce the new audio stack in Windows.  For beta 1 the stack was present but didn't do much the old stack didn't do.  If we did our jobs right, all that work would never be noticed.  If we screwed up, things that worked before wouldn't work now.  For Beta 2 we are able to add all sorts of cool new features on top like per-app audio. 


   The point here is the early releases of the operating system (or any application going through a major overhaul) is going to look worse before it looks better.  Take heart those of you watching the process unfold.  Vista will be an exciting OS with lots of cool new features.  I've seen some of the recent Beta 2 builds and it is looking much more impressive.  I can't say anything about it but if you watch places like Channel 9, you'll probably see some of it soon.  You can also see some of it in the PDC demos which were given about a month ago.


  

Wednesday, September 28, 2005

Programming for the next guy

   I'm taking a class this week.  The subject is writing WDM drivers.  The class assumes you have some understanding of how operating systems work and teaches you everything you need to know to be prepared to write a WDM driver.  It isn't a cookbook class.  I won't come out and write a driver without needing the DDK but I will have enough understanding to be able to read the DDK and fill in the connections between all of the parts.  I find that when trying to learn something, rather than being told exactly what to do, I learn best by getting a high-level view first and then diving into the details.  This class is taught in that way and I highly recommend it.  The class is offered by OSR.  It is being taught by Peter Viscarola (author of Windows NT Device Driver Development).  If you are new to driver development, take this class.


   The class isn't the main point of this post, however.  Rather, it is some advice that Peter gave a few times during the class.  Someone might ask a question like "Can't I do x in some funky way?" and he would answer, "You could, but no one would expect to see it so don't."  The point he was making is that we, as programmers, should stay away from being clever.  We should, as much as possible, try to do things the same way everyone else does them.  Why?  Because you won't be the only person to work on this code.  Even if you are, the next time you touch it might be a year or two from now.  If you did something clever, the next person to touch it will look at the code and not immidiately understand.  This will have one of two consequences.  Either they will have to spend 10 minutes just trying to understand what it is you did or, worse, they will assume you made a mistake and "fix" it by making it less clever.  Neither of these results is desireable.  Unless you are writing one-off code for yourself* you need to write it in a manner to make it easily understandable so that it can be easily maintained.  This is the intent of the smell test talked about by the authors of Refactoring or of the self-documenting code the XP advocates talk about.


   To be more explicit, whenever possible, follow conventions.  If you aren't the first one to be doing something, don't reinvent the wheel.  If you aren't sufficiently familiar with your domain to know the conventions, it would behoove you to spend some time becoming familiar with how things are done in that space.  Doing so will save lots of time and effort later.


 


* Useful one-off code often ends up not being one-off code.  Always code like you'll be maintaining it.  Someone probably will.

I'm back. Hopefully.

Wow.  It's been a while since I blogged.  I have a lot of ideas but I've been quite busy of late and haven't gotten to them.  I was out of town for 5 weekends in a row from late July through August.  Needless to say, that doesn't leave a lot of time for other stuff.  Hopefully I'll now find, no make, the time to do that. 

Friday, July 15, 2005

OS/2 Finally buried

IBM finally announced the official, final death notice for OS/2.  Back before I joined Microsoft I was one of those who was attempting to jump on the OS/2 Warp bandwagon.  When I was in college I would read about it every week in PCWeek (now eWeek) and was impressed with its capabilities.  I even went so far as to purchase a copy.  $100 was a lot when Win3.1 came free on my Pentium 75.  Even after Win95 came out, I kept trying to run OS/2.  The problem I ran into with OS/2 (which is the same problem I ran into with Linux years later) was that, while the OS had lots of cool features and was, on paper at least, better than Win95, there just wasn't much software for it that could compete with the software for Windows.  Having a shiny new OS with nothing to run on it is like buying a new car but not having a drivers license.  It looks really cool but just isn't that much fun to use.  Now, a decade or so later, it's finally being officially put out to pasture.