I knew I wanted to write a blog post today and I really had two choices.

1. Join in the debate over whether or not you need to know C in order to be a real programmer.

2. Talk about the Wii Fit

Lots of people are talking about choice number one. Well, perhaps talking isn’t the right word. Flaming? Fighting? Insulting one’s intellect? Yeah, any of those would do.

But we can bang that one out quick; here I’ll take a stand.

Do you know C? – Yep.

Have you programmed in C? – Double yep.

Have you programmed professionally in C? – Yes.

Would you do it again? – Wouldn’t be my first choice but sure why not?

Do you think programmers should know about pointers and memory management? – Couldn’t hurt them. Not that it makes it any fun though. Screwing that stuff up, and it always gets screwed up, results in errors in fun and terrible ways.

Ok, now that that is out of the way on to the Wii Fit. Thanks to the magic of Amazon pre-orders ours arrived yesterday morning. By the time I made it home from work my wife was actively playing the hula hoop game on the Bluetooth scale board thingie while my three and a half year old daughter was standing three feet to the side making hula hoop motions.

Somehow I think Mario Corp. has a winner here with the new to gaming/super casual gaming crowd.

(And what about the Wii Fit commercial with the woman busting out the Yoga? I’ll bet they sold an extra bazillion units on that alone.)

Now we ran through all the unlocked games and exercises last night, and I doubt that it will cause any kind of gastric bypass like results, but one thing does stand out. The silly thing is fun. Who would have figured, balancing on a couple of scales to roll a virtual ball on a virtual board through a virtual hole is in demand entertainment these days.

We’ll have to see how long it keeps our attention, but I suspect with a couple people in the same house playing it the novelty won’t wear off as fast. In fact, I’ll bet right now my high scores on the balance games are being mercilessly attacked while I am hard at work blogging, err, working.

Oh, and to complete the circle from earlier, like all games it’s probably written in C. So if being a real programmer means writing pseudo-exercise console games it looks like C is indeed required.

Well, it might also be C++, but that’s really just C with a compiler messages that read like you strangled a cat.

Today while I was doing some work I had the most recent Macbreak Weekly podcast going in the background. For the second time in the last few weeks one of the hosts via Skype was sounding an awful lot like a Cylon. It turns out the problem was the USB port on their Macbook Pro’s, specifically they were plugging their microphones into the one on the right side.

*Pauses*

*Scratches head*

The deal, it turns out, is that the USB port on the right hand side is connected to an internal hub that runs all the other devices like the keyboard. What this means is that there isn’t as much power to go around and it causes power hungry things like a microphone to behave oddly. The one on the left hand side however is all by itself so with it everything works great.

I find this interesting because the very same thing happened to us when we were recording some audio here. At the time we thought my MBP USB port was ok but that Jeff’s was broken because mine would work while his wouldn’t. Our theory was supported by the fact moving his connection to the left allowed it to work.

(That’s the standard by which to measure broken by the way, when one works and another does not.)

So that’s the scouting report for today, if you are having USB problems on a Macbook Pro try having it pitch left handed.

I was, as always on Wednesday, finishing up watching the latest Zero Punctuation review over at the The Escapist when I noticed that they had a new video that is a tour of Epic Games. Epic happens to use TestTrack Pro and it’s always fun to see the inside of a place where our stuff plays a part.

Well, unless the place is a sausage factory. Somehow I think that would ruin pork products for me and that’s way too high a price to pay.

Anyhow, below is the video (slight off color language, consider yourself warned) and here is the associated written article. The joint looks cool and I’m happy that they use our product. All that being said however, I suddenly have the urge to go blow something up…

A couple of weeks ago I did a little write up of my favorite features from Surround SCM 2008.1. Unfortunately, afterward I kept getting requests from the TestTrack guys about when I was going to do the same thing for that product. Seriously, night and day, just question after question.

Well, not really, but I’m sure they thought about it. Maybe they forgot to send an email.

Or call.

They never call.

*Sigh*

Anyhow, I had been planning on doing it when the next significant release came out. That all changed this morning.

Jeff and I were talking about the whole single vs. double space after period boondoggle when he mentioned the new TestTrack release, version 2008.1.1. Typically I don’t think much about bugfix releases unless there is some bug that is really annoying me. He claimed, however, that there were two new features in this one. Feeling skeptical I fired up the client to have him show me what had been added.

Oh sweet mother of all that is good in the world hallelujah. I knew these things were coming but I didn’t know it was going to happen now. It’s kind of like finding out that Easter has been moved to today and that the Easter Bunny has left you a basket containing a BMW.

Here is what the defect overview tab looked like before. Notice that the description section has all the line breaks removed making it hard to read for text with lots of paragraphs.

He is what it looks like with the brand new “Show Line Breaks” checkbox checked. That is so much better I can hardly explain it.

The other feature is similar and can be found on the Workflow tab. If you have lots of automation rules set up (which you should) this list can get littered with System Comment items making it hard to see the stuff that a real flesh and blood person did.

But if you uncheck the “Show System Comments” checkbox you get just the actions from the living.

At this point I could feel the eyes water up a bit, but I had to keep my composure since I had someone standing over my shoulder. You know how it is, I’ve to go protect the street cred and all. I’ll leave it at that, there’s really nothing else to be said. Go download 2008.1.1 right now and improve your life. You owe it to yourself.

Man did I start something today. So I’ve been working on an article that is due in a week or so and the first draft got reviewed today. One of the first comments in the Word document read like this:

“FYI—the standard now is one space after end punctuation. I replaced all the extra spaces but didn’t track them.”

Whaaaaa?

You’re supposed to use a single space after end punctuation? Really? Where did that come from? How long has it been this way?

This naturally led me to walk around and ask anyone I saw how they do it. My unscientific survey came up with nearly a 50-50 split broken into these two camps:

“You use two spaces?”

“You mean you’re only supposed to use one space?”

The latter group typically then had an existential moment where they considered what else is wrong that they thought they knew. At one point the single space people (Jeff, Paula) were standing looking at the double space people (Me, Alan, Tom) with all of us trying to decide which group was crazier. Even the Word grammar checker couldn’t take a stand by making the number of spaces a configurable option. (The weasel.)

I understand the reason for it, typewriters with mono-spaced fonts versus computers and all but I am still shocked that it took until today for me to find this out. What’s even more bizarre is that arguments over this have been happening on the Internet for years.

I still haven’t been able to peg a date on when this changed happened so I would love to know. Until then the one argument that really swayed me toward single space (ignoring of course all the official style guides and typesetters that say it is the way) came from the Wikipedia Manual of Style

“The bottom line for me, however, is the Emacs commands for moving between sentences: M-e moves forward one sentence and M-a moves back one sentence. These two commands are really handy. If you need to navigate long, unbroken lines, like when editing Wikipedia, they are to live by. Oh, but they only work properly when two spaces are put between each sentence.”

If double spaces are the emacs way of doing of things I think it is pretty clear I need to hunker down and teach myself not to do it anymore.

After passing this along to at least three different people I’ve decided to post it here. That Merlin Mann makes me laugh.

Isn’t fun to be blamed for doing something wrong when writing code? Nothing quite like having QA, or even worse a customer, find some major issue with something you wrote. Writing software is a hugely personal thing; there is a tendency for developers to think of their code as reflection of themselves. So when a big screw up occurs, the stages, not go all Kübler-Ross on you, go kind of like this:

Denial: “That’s not my fault.”
Anger: “Why were you using it like that anyhow?!”
Bargaining: “Let me just do a quick a fix, you don’t need to write it up.”
Depression: “How could I do that? I don’t deserve to use a compiler.”
Acceptance: “Oops. I should fix that.”

The question for the day then is how do we make writing software less a reflection of self? Let’s take a look at how one place tackled this.

The classic example that comes to mind when talking about projects that need high quality software is space travel. And why not, it has all the traits of good storytelling. Massive amounts of money, it’s incredibly dangerous, and if one tiny thing goes wrong it becomes a huge news story.

See Orbiter, Mars.

There was an article from a while back that talked about the on-board shuttle group of the Lockheed Martin space division. It it gives us a not surprising peak into the development process of writing software for the space shuttle and the steps they take toward having extremely high quality. From the article:

“This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program — each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.”

It also mentions why the quality is so critical:

* Shuttle costs about $4 billion dollars
* Lives of astronauts
* The focus of a nation

“Bill Pate, who’s worked on the space flight software over the last 22 years, says the group understands the stakes: ‘If the software isn’t perfect, some of the people we go to meetings with might die.’ ”

Brings a whole new level of seriousness to it doesn’t it?

I read a fair number of developer focus message boards and a recurring theme is the desire for things that are standard issue in this group.

* Everyone has an office
* Strictly 8 to 5
* They are mostly adults with spouses, kids, and lives outside of work
* A single client with a single platform
* There are essentially infinitely deep pockets thanks to the US government

I’m sure if working conditions like this were posted on the same forums there would be a digital stampede of resumes flying in. There is a downside though. Many time developers try to sell what they do as being part art, but from this next list there doesn’t appear to be much painting or songwriting.

* Planning, planning, and then some more planning
* Mountains of designs and specs
* Everything is reviewed, reviewed, and then reviewed
* There is no creativity. There is one way to do everything.
* No more stacks of Mountain Dew and empty pizza boxes.

It has been my experience that these items are the bane of the normal developer. Heck, one could argue that an entire methodology of software development has been created to stay away from this stuff.

There’s a bunch of other really interesting things in the article but it is the final of their four key tenets that really stuck at out me, and the one that answers our question from earlier is:

“4. Don’t just fix the mistakes — fix whatever permitted the mistake in the first place.”

This is really critically important, the concept of blaming the process and not the person. As soon as developers start getting defensive is when things like code reviews and refactoring become toxic operations. The shuttle software is certainly an extreme case and requires a level rigor not even remotely close to most software development but I can’t help but imagine that the process improvement/blame business would be useful. Once everyone bought into it the whole thing might even be embraced and quality would go up too.

I don’t know, for the cost of less soda and pizza it might just be worth it.