I've recently been involved in a project focused on developing teaching materials for High School Computer Science courses. As I've thought more and more about my experiences as a student and professor in high school and college CS, I've noticed some clear patterns in my evolution as a developer and those I've worked with over the years. Reading Alfred Thompson's recent blog entries on teaching students to comment (here and here) got me thinking specifically about how commenting and other non-algorithmic techniques have really improved the quality of my development experience over the years.

While teachers can try to pound away at why students should follow certain coding practices, it seems as though everyone needs to have their own personal epiphany before they can truly appreciate why certain mechanisms exist in CS. I think the reason that most students shrug off many of these development best practices is that they are primarily useful during debugging, which is where the vast majority of professional developers spend the vast majority of their time. Students, however, can often get away with completing their assignments on a single printed page, so debugging barely even enters the equation.

Thinking about how I've changed over the years, I can identify three specific ways (in evolutionary order) I've grown:

1. Commenting. Sure, everyone says you need to comment, but it's not until you have to read someone else's code (or try to read your own from years ago) that this really starts to hit home. Code without comments is almost a sure F on any homework I've ever graded. Sure, the algorithm might be correct, but that doesn't mean you've done a good job engineering the software. Commenting is a key tool for communicating what the code does. Trying to debug someone else's code without having useful comments really sucks.
2. Naming conventions. Some people argue in favor of Hungarian (fewer and fewer these days) and some against (the rest). The one thing that everyone agrees on is that you have to be consistent, whichever direction you take. Naming conventions need to go beyond variables and touch on methods, events, delegates, classes, etc. While I don't agree that a good naming convention can remove the need for commenting, I do understand why many people preach it. Using useful names like "numberOfIterations" explains what a variable is for as well as any comment could. The official naming guidelines from MS are a very useful tool here.
3. The Debug class. I must admit that it took me much longer to warm up to the Debug class than I would have ever expected. I never really saw it used in many samples or solutions, so I just figured it was only offered to keep a small segment of the development population happy. Boy was I wrong. Debug.Fail and Debug.WriteLine are two of the most useful debug tools out there. While I love breakpoints and the call stack and so on, the Debug class is my best friend when it comes down to algorithmic debugging. For those who haven't touched the Debug class, Debug.WriteLine will send a string to any debug listeners (by default just the Output window in VS), Debug.Fail will stop execution to display a message, after which you can either ignore the message or press "Retry" to debug.

So how does this all of this relate to my title, "Why I Hate Debug.Assert"?

As I've mentioned, the Debug class is awesome because it enables you to do debugging stuff at runtime (such as logging and breaking into debug mode). When you compile and build in "release" mode, all of the debugging stuff gets stripped out, leaving you with more optimized code. This makes it very easy for you to develop and test in debug mode, and then not have to do anything besides change the build configuration when deploying (in other words, you don't need to comment out or delete the Debug class calls).

This is where the problem occurs. When I see code like this:

public void MyMethod(MyClass myClass)
{
    Debug.Assert(myClass != null, "myClass is null in MyMethod");
    myClass.DoSomething();
}

I end up screaming "You were SO close!!!".

In this scenario, a null might get passed in as myClass and the developer will hit the assert, which will pop the Assert dialog that they can use to stop execution and discover why myClass was null when MyMethod was called. They'll fix the calling code and run it again. Everything will work, they'll build it for Release, and toss it over the wall. Unfortunately, this code isn't robust because it's still possible that null could be passed in (unless you have absolute faith in every caller, which you shouldn't).

Alternatively, the better solution is:

public void MyMethod(MyClass myClass)
{
    if (myClass == null)
    {
        Debug.Fail("myClass is null in MyMethod");
        // either return here or throw and exception, but don't let execution continue in release mode!
    }
    myClass.DoSomething();
}

Now we get all of the benefits of the Debug class, but maintain a level of robustness for Release code. Sure, if this comes up you'll still need to debug, but at least you'll get better detail than a NullReferenceException. It's also possible you could even recover from this somewhere up the stack.

I can't really think of any place Debug.Assert is better than Debug.WriteLine (if just logging) or Debug.Fail (as described above). Then again, I could be wrong!

8/14/2005 10:28:34 AM (Pacific Standard Time, UTC-08:00)      Comments [5]  

I came across a very interesting post from Scoble this morning regarding Mary Jo Foley's recent article about Microsoft needing to come clean about exactly what's in Vista and what isn't. My favorite part (perhaps a little out of context) is:

"You know, I'm afraid of writing about Windows Vista. Why? Because we went out so early and created so many lofty expectations last time (big mistake) that I just wanted to crawl in a hole and say nothing. Which is pretty much what I've done now for about a year. Plus, Windows is such a big product, with so many people involved (thousands), with such high expectations on it, that saying anything without really understanding all the pieces is just asking for trouble. There are only a few people who understand all the pieces, and they are just hard to get face time with."

You see, when I was asked to take on WinFX product management in early 2003 (actually, it was LAPI product management at the time) it was very clear that there was one goal set an order of magnitude higher than all others.

Planning? No.

Messaging? No.

PR? No.

None of these?!? So exactly what else do product managers do?

Well, it's pretty simple. At the time (years before beta) it was clear that people had incredibly high expectations on what would be shipping. My job--which was more politically than technically challenging at times--was to preserve as much developer value in Longhorn as possible. This basically broke out into 3 things:

1. Helping teams prioritize what got cut. Longhorn had so much planning and design work done by the time I got there that the product was in its "absolute best case scenario" mode. We knew that things had to be cut in order to ship this decade, but the question was about what things were most important to developers, which would be used, which would be appreciated, which could be supported, which could be backported to XP, etc. Keep in mind that I couldn't just fire off an email saying "hey, I noticed that you guys have 7 FTEs on this, but every customer I've talked to said it's not interesting to them so could you please refocus them on this other feature people really care about so it ships?" People are very reasonable about cutting features in order to ship--unless it's their feature and then you can go fsck yourself.
2. Helping teams do the stuff that was important in the right way. I didn't lead any of the efforts here, but got to participate in some of the most interesting programs. For example, there are multiple reviews of every API going into Longhorn (and other products) that are run by the API design gods, Brad and Krzysztof. I learned more about architectural design from the WinFX API reviews than I thought ever existed. One other thing I'm proud of was the amount of effort put in to help make a case for bringing Avalon downlevel. It was clear pretty early that this was the only way to get people to invest in it this decade, although it introduced a whole world of challenge regarding system requirements, etc.
3. Finally, I had the fun role of trying to get people to STOP OVERSELLING LONGHORN. This was probably the single worst part of any job I've ever had. Keep in mind that the ratio of product managers to Longhorn evangelists at the time was 1:21! I was expected to go meet with program managers and devs who were working fulltime on feature X for 2 years and ask them to not do a webcast or blog posting or conference session because it didn't seem like their feature would ship. I got love letters like this one all the time (which I remember having been much less friendly at the time--maybe it's been edited for today's 2-year anniversary ). I also remember getting my ass kicked in meetings every day--just imagine being the one guy in the room saying "Maybe PDC 2003 shouldn't be the 'Longhorn' PDC"!

At the end of the day, overselling Longhorn might have set expectations too high, but sometimes that happens. Things still turned out pretty well and will get better now that the bill of materials for WinFX and Vista are getting clearer. I still maintain that WinFX is going to be a great platform and Vista will deliver on what the vast majority of customers really care about (security, reliability, etc). In the end, that's all anybody really cares about.

8/11/2005 9:22:53 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

...I am definitely not Steve Ballmer's girlfriend. However, I can't deny that I am now the #1 hit for it on their search engine (I noticed due to the spike of referrals it gives me).

My theory is that my recent #7 post tore some sort of hole in the Space-Time Continuoogle(TM).

8/8/2005 2:39:31 PM (Pacific Standard Time, UTC-08:00)      Comments [3]  

My old boss just announced the official names for Avalon and Indigo. While I'm still not thrilled with "Vista", I definitely like how these two turned out. It was pretty obvious that Avalon was going to be "Windows Presentation [Something]" and Indigo would be "Windows Communications [Something]", but "framework" sounded too unfinished and "services" sounded too much like "services". I even heard a rumor that "Windows Service Model" was a proposed name for Indigo at one point! Regardless, I like "foundation" much more because it's clearly something that's solid, ready to be built upon, and has a broad surface area.

On the downside, this will have an immeasurable impact on the black turtleneck and beret consortium. I'll also miss the old days sitting around the campfire chatting up the MPRSCNAAIB1RC (Microsoft® Pre-Release Software Code Named “Avalon” and “Indigo” Beta1 RC).

7/27/2005 11:23:41 AM (Pacific Standard Time, UTC-08:00)      Comments [0]  

I just found out that I am the 7th google result for "steve ballmer's girlfriend". Go figure.

MSN seems to do a much better job separating fact from fantasy. A boy can still dream, can't he?

7/26/2005 9:38:40 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

I consider myself to be a pretty experienced .NET developer and well-traveled human. But even with these staggering credentials I managed to learn some really useful things at Portland Code Camp. For example:

1. Chris Tavares knows a much better way to build a plug-in model for your app than I do.
2. Cathi Gero knows a much better way to ensure a single instance of an app is running than I do (it's amazing how easy it is).
3. Everything I use has a better replacement, but you have to parse this page to figure out which ones they are.
4. It is much harder to present to an audience of 3 than it is to present to an audience of 300. This I learned in my .NET CF 1.0 overview session. Then again, if I had the option to see Scott Swigart talk about VB Fusion, Steven Borg talk about SQL, or Ted Neward talk about Indigo, I'd probably have skipped my own session too! How can you compete for audience market share with that kind of lineup?
5. If you sit in the back seat of Scott Hanselman's car you will need his permission and assistance to get out. The bright side is that the car is run entirely on sarcasm and gets 2 miles to the comment/gesture.
6. Richard Davis will not complain about anything. Then again I already kind of knew that.
7. Driving from Redmond to Portland and back sucks. There is a ton of traffic and no good reason.

You can find some of the answers to these things from the PCC link above. Others are life experiences you can only get from future code camps.

7/25/2005 2:01:50 PM (Pacific Standard Time, UTC-08:00)      Comments [0]  

I've gone through just about every emotion regarding the official new name for Longhorn. At first I was really disappointed, but I've come to accept it and think there will be so much marketing that the term Vista will have a completely different meaning to me (those Windows Client marketing guys can really get into your head!).

Here are some of the downsides (before I forget):

1. To me, "Vista" sounds like the name of a failed product from a generation ago. Seriously. "Windows Vista" sounds like it should come with wood paneling and a built-in 8 track.
   1. "Hey, remember that Chevy Vista automacar that blew up if you closed the gas cap too tightly?"
   2. "Hey, remember that DEC Vista computomatron that blew up if you rested your coffee mug on it?"
   3. "Hey, remember that GE Vista refrigamerator that blew up if you put the carrots on the top shelf?"
2. It doesn't have built-in obsolescence. One of the questions often asked on marketing interviews is whether "Windows 2000" was a good name for the product at the time. Yes and No are both valid answers, but you need to explain your reasoning. In a nutshell, "Yes" it was a good name because people cared a lot about Y2K and having "2000" made it shiny and new in 2000, but ready for upgrade by 2005. "No" was a good answer if you pointed out that every Windows [year] model has been for a consumer audience, whereas Windows 2000 was intended for a business audience. ME, ironically, came out for consumers, who were used to having letters indicate the business product (NT).
3. Vista (aka "View/Vision") is a little too self-prophetic for my liking. It also doesn't promise anything I care about. I liked Windows 2000 because it squared in on Y2K. Windows XP (eXPerience) was clear about improving the user experience and shell. Vista kind of tells me that it's going to look more like a Mac (in the words of someone else, of course) but not in an inspiring way.
4. Vista doesn't sound corporate-friendly to me. It's kind of toyish. This probably doesn't matter since there is no reasonable corporate alternative to Windows. I do remember people telling me that they would install XP and immediately revert to the 2000 look & feel since they thought clients wouldn't take them seriously for using the "cartoony" XP shell. I'd rather have XP over 2000 any day.

Then I spent some time getting into the heads of people. I started wondering "what's the angle here?" There's always more than meets the eye. Here are the upsides, as I see them right now:

1. Pegging a product to a year so far before it ships is bad voodoo. Visual Studio 2005, for example, might not ship until 2006. Yes, I know the ship date is in 3.5 months, but there is still a possibility that it won't. Having a 2005 product ship in 2006 looks bad, just like having a 2006 Windows ship in 2008 would look bad. I'm not saying it will or won't happen, but not using the year number in the name is a safe bet.
2. If you put your Mac hat on (plenty of Windows evangelists never take theirs off) you'll notice that the "VI" part of Vista is the roman numeral notation for 6. I don't know if it's time to move to Windows 6 but this is a subtle way for the geeks to have something to hold near & dear.

I never really loved Longhorn as a final name, but it was a great codename and I'd rather keep it for final over Vista. If you're going into a fight, do you want "Longhorn" or "Vista" in your posse? Well, which is it? Shotguns or show tunes?

In the meantime I'm going to sit back and wait for the mind-numbing commercials so I can accept it. "The Windows is good! The Windows is great! Vista is too! As of this day!"

Then again, who really cares about the name? The OS is going to be absolutely fantastic. They could call it "Strawberry Windows Shortcake" and I'd repave my machine with it an hour after RTM.

7/22/2005 9:23:58 AM (Pacific Standard Time, UTC-08:00)      Comments [3]  

Sean Gephardt linked to a paper by Bjarne Stroustrup on his thoughts for the next generation of C++, C++0x. While I think it's interesting to see some of the improvements, it's disappointing to not see more overlap with the concepts being driven in C++/CLI. Some of my favorite component-oriented things in C++/CLI were noticeably left out from Stroustrup's paper:

1. The concept of having "internal" classes and methods provides a great way to prune the interfaces to libraries, which guides developers in using them.
2. It would be great to see source commenting (such as XML comments) introduced and standardized.
3. Properties are pretty awesome.

I know the new standard proposal for C++0x is still early (that's why there's an 'x'), but hopefully some of these ideas can permeate. Sure, these things aren't entirely syntactical, but it would be great to have them. They all make developers more productive and cut down support costs.

7/11/2005 10:25:43 AM (Pacific Standard Time, UTC-08:00)      Comments [3]