Just a quick note.  I've disabled trackbacks for a while since I've been getting more trackback spam than actual trackbacks.  I've got a couple changes to make to the code base I use, and will re-enable them when those have been completed.

I wonder how many companies exist out there where this has happened to them:

Of course the reality is that the guy wasn't all that smart... he just thought out of the box so much, that he was unable to write intelligible or logical code, and didn't know enough English to write proper comments.  And when I say he didn't know enough English, I'm not saying he was an H1B from another country... there are plenty of locally grown computer geeks that have a problem mastering their own language as well.

Prior to interviewing at a company a long time ago I was given a test by a staffing firm in order to test my knowledge of C++, which at the time was my language of choice.  It was a timed test, and by the end of it I had a massive headache.  Each question was filled with code written so poorly, with so many uses of pointer indirection, and non-standard pointer dereferencing, that I almost screamed.  At the end of the test they gave me an opportunity to provide feedback, and I said something along the lines of:

To be honest, I hope I failed this test.  I would never want to work with anyone who passed this test, because that means that they write code like this often enough to be able to answer your questions correctly.  People who write code like this are not good programmers.

It goes without saying that the staffing company didn't offer me a position, though I barely passed the test.

To be honest, I'm still not quite sure exactly what "Agile Methodology" is.  I've read several books on the subject, and there are plenty of companies out there that like to think they use parts of it in their development process.  I say "parts" because they really just cherry pick the things that they thought they could sell to management without changing too much of their current process, yet still sound like they're on the cutting edge.  There are so many different versions of "Agile Methodology" out there, it's enough to make your head spin.  That's why this blog post is so damn funny:

Yeah. Well, they make money hand over fist, because of P.T. Barnum's Law, just like Scientology does. Can't really fault 'em. Some people are just dying to be parted with their cash. And their dignity.

The rest of us have all known that Agile Methodologies are stupid, by application of any of the following well-known laws of marketing:

- anything that calls itself a "Methodology" is stupid, on general principle.
- anything that requires "evangelists" and offers seminars, exists solely for the purpose of making money.
- anything that never mentions any competition or alternatives is dubiously self-serving.
- anything that does diagrams with hand-wavy math is stupid, on general principle.

And by "stupid", I mean it's "incredibly brilliant marketing targeted at stupid people."

Not only is Agile like cholesterol, it's also like Scientology and your local circus.  It's probably the most sensible look at Agile that I've read so far.  Via Joel on Software.

Update: And here is the response, from Coding Horror:

Rather than wasting time and effort on discriminating between "good" and "bad" Agile, we should be banding together in the name of Anything But Waterfall. The fact that some maladjusted developer or project manager could use Steve's well-written, reasonable sounding rant as a justification to keep their project in the dark ages of Waterfall and BDUF absolutely kills me. Who is the real enemy here?

Read the whole thing.

I am very proud of the fact that I do not have a single piece of DRM protected music on my computer.  Period.  I want to own my music, and be sure that if I buy a new device, it will play said music.  Period.  Here is a perfect example of why I do this:

In yesterday's announcement of the new Zune media player and Zune Marketplace, Microsoft (and many press reports) glossed over a remarkable misfeature that should demonstrate once and for all how DRM and the DMCA harm legitimate customers.

Microsoft's Zune will not play protected Windows Media Audio and Video purchased or "rented" from Napster 2.0, Rhapsody, Yahoo! Unlimited, Movielink, Cinemanow, or any other online media service. That's right -- the media that Microsoft promised would Play For Sure doesn't even play on Microsoft's own device. Buried in footnote 4 of its press release, Microsoft clearly states that "Zune software can import audio files in unprotected WMA, MP3, AAC; photos in JPEG; and videos in WMV, MPEG-4, H.264" -- protected WMA and WMV (not to mention iTunes DRMed AAC) are conspicuously absent.

That's right.  Microsoft's own player won't even play music that has been protected by the DRM format they pushed.  From a business perspective, this is just stupid.  Microsoft has actually had a very strong history of backwards compatibility.  Windows is a great example of this commitment.  Why they're screwing their customers now, for really no good reason, is a complete mystery.

But more to the point... my faith in the MP3 format is once again justified.  Via Slashdot.

Do you know how much of a geek you are?  If not, here's yet another test you can take to find out.  As for me...

You are 57.5% geeky.

Not bad. Maybe you spend a little too much time with your computer, but at least you have friends. You do have friends, right?

The current average score is: 31.07%

Fact: 35.69% of people who took this test admit to wearing a costume "just for fun".

Another Fact:  I was not one of them... and I'm sticking to that answer.  Via Samantha Burns.

This applies to more than just computer geeks.  You see this in any specialized profession, especially ones that require great technical prowess or accomplishment.  That's right, even doctors and lawyers can be like this.  In some cases it's being known as a team player, or just personable, or having good bedside manner.  Often times, this is how people unfamiliar with your profession measure your ability.  If you have good bedside manner, then you must be a skilled surgeon.  If you can relate well to a client, then you must be able to write wonderful briefs.  If you're not a cubicle recluse, you write great code.  Of course this is entirely false.  In fact, often times it's the exact opposite.  People who are the most introverted are often times the most skilled at their profession.  But because they come off as shy, or maybe even rude, it's assumed they must not be good at what they do.

In my experience, some of the most clever, most skilled programmers have been very introverted, and very reclusive.  They're the type of person who sits in their cube, and won't interact with you unless they have to.  But the code which they produce is very high quality, and they have a very deep knowledge of software.  Having spent part of my career hanging out in hospitals, I don't know how many times I've heard from nurses about about a doctor with terrible bedside manner, who was the best surgeon they knew of.  Often times I think serious professionals tend to sacrifice the development of their interpersonal skills in order to concentrate on the technical aspect of their job.

I write this for two reasons.  First, it's important to recognize this about yourself if you know you are this type of professional.  People will judge you, fair or not, based on your ability to communicate well with others, even if it is not the most important part of your job.  Of course, the ability to work well with others, and communicate effectively with patients or clients ought to be a highly desirable skill anyway, and so if you should recognize that it is a reflection on you, and try to improve.

I also write this to make others aware of this.  Don't judge someone purely based on their interpersonal skills.  While it may be important, it's often times not the most important skill to have for a position, and you may be passing up on someone who would do an incredible job for you.  Moreover, someone who can talk a good game my not have the chops when it comes down to actually doing the job you hired them to do.  Don't use one as your only measuring stick for the other.

One of my coworkers forwarded me this link, which has a great pictorial analysis of how the software development process works.  It's priceless... and something to always keep in mind when you start a long running project.

I review a lot of code during the week... it's one of the more interesting parts of my job.  It's amazing how certain patterns just sink into you brain after you review enough code.  Recently a coworker was in my cube asking about what a particular section of code was supposed to do.  We were looking at my monitor when the following conversation took place:

Coworker:  What does this do?
Me: Well you wrote it, why don't you tell me.
Coworker:  I didn't write that code.
Me:  Yeah, you did.
Coworker:  I never change anything in that project.  You're the only one who works in there.
Me:  Trust me.  I didn't write that code.  I would never write an If statement like that, and that's not how I write comments.  That looks like one of your If statements to me.
Coworker:  What?
Me:  Here, let's take a look at the Source Safe history log.

Sure enough... after just a few minutes in Source Safe, it was revealed that he added the code in question.  It's funny how easy it really is to pick out one person's code versus someone else's.  I can differentiate code written by pretty much everyone on my team just by looking at a few lines.  People have different commenting styles, and different spacing conventions that they like to use.  People leave fingerprints in their code that they don't even realize.

So then we sat around for a few minutes and I showed him his fingerprints.  I showed him how his If statements were subtly different from mine, and how he comments differently.  I didn't do this to correct any flaws... because there weren't any.  It was simply a matter of coding style.  It is important to at least be able to recognize your own code though.

Make your TODO's TODONE!

I'm not actually a project manager, but I do share in some of those responsibilities on my current project, in so far as I'm considered the lead developer and architect.  One of things that I've learned over the years, and I try to push for before every major release to production, is to have all the developers on the team go through their code and clean up TODO's.  Today was a perfect example why.

Right now we're working on a 2.0 release, which involves a lot of rewrite since the 1.x branch.  However, we still have to support the 1.x branch which is in productions until we release 2.0.  Friday we got a call for a production problem, and we were able to narrow down the problem this morning.  When I found the offending code, there was a TODO which described the fix that needed to be made.  The defect was actually rather obscure, and I'm surprised it came up... but nonetheless... someone at some point in time anticipated this happening, and stuck a TODO in there which perfectly described what needed to be done to fix the defect.

Had that TODO been turned into a TODONE... this problem would never have occurred.  At some point in time prior to a release, you should always go through your code and try to get to a 0 TODO count.  Granted, this rarely happens in real life, but you should at least evaluate every TODO in your code to see if its really still an issue.  TODO's that are in code too long should also be noted in defect logs as well, so that they begin to elevate the chain of importance, and can be evaluated with other code changes that have to be made.

Finally, all TODO's should have initials next to them.  A one line TODO can often times be very vague, and so its helpful to be able to go back to the original offender and get more context from them as to why they put in the TODO.  Sadly, this particular TODO was nameless, although it was fairly descriptive.