Standing in the rain, with his head hung low, couldn’t get a ticket, it was a sold out show, heard the roar of the crowd, he could picture the scene, put his ear to the wall and like a distant scream, he heard one guitar, just blew him away, saw stars in his eyes and the very next day, bought a beat-up six string in a second hand store, didn’t know how to play it, but he knew for sure that one guitar felt good in his hands, didn’t take long to understand, just one guitar, slunk way down low, was a one-way ticket, only one way to go, so he started rocking, ain’t never gonna stop, gotta keep on rockin’, someday gonna make it to the top and be a Jukebox Hero….

Jukebox Hero, Foreigner

It’s my understanding that once a musician reaches a certain level of notoriety, they are often asked how they got their start, so that the fan can obtain the level of success that the musician has obtained. Over the years, I’ve received quite a few of these kinds of emails, all of which flatter and surprise me, since I don’t feel like I’ve obtained the level of success that I’d like to. Still, I’m happy to offer, if not advice, than a list of what I did to obtain a level of recognition in our little circle.

It all started in early 1994, when I went to work for DevelopMentor. Don’s strategy, which remains in place to this day, was to give every instructor the opportunity for “stardom.” He had just started to obtain his own notoriety in the industry with his flamboyant personality, teaching and answering every other question on the DCOM mailing list. From there, he used his political acumen to make friends with conference organizers and book publishers, working to add the same level of rigor to Windows development as he was accustomed to applying in the pursuit of his PhD.

Since Don is a fellow that gains happiness in togetherness (or, put another way, “misery loves company”), he dragged the rest of us into his world of course authorship, 24x7 mailing lists, speaker anxiety, article deadlines and demanding book editors. To find my place in this world, I did the following, leveraging the success I had in the early work to make the later work happen:

• Answered every other question on the DCOM and ATL mailing lists and continue to be very active on the .NET mailing list.
• Wrote and gave numerous courses and conference talks.
• Wrote a number of books and articles.
• Put up a web site dedicated, initially, to the various bits and pieces of code I’d built and then expanded it as I had more to say (which turned out to be quite a lot, apparently : ).
• Took as much consulting as I could to gain real-world experience, which I put into my other work.
• Asked fans and happy clients to post their comments on Amazon or allow me to post to my own web site.
• Crazy things just for fun, e.g. pose naked or misinterpret an email on purpose in order to post a humorous response.
• Made friends with the owners and producers of the technology in which I was interested.
• Threw a couple of conferences.
• Started (and stopped) a department to build software developer tools.
• Launched my own (budding) software development tools.
• Launched a couple of source available projects with folks from the community.
• Launched my own mailing list.

It seems like a lot, but practically everything I’ve done since 1994 has been published with my name on it, making me as much an agent for myself as an actual “musician” (I believe the phrase is “shameless self-promotion” : ). Based on this experience, here are the guiding principles that I try to follow:

• Do the right thing. My father always used to say that anything worth doing was worth doing right and that the right thing was easy to spot — its was the hardest.
• You can’t win if you don’t bet.
• Be very thorough so that I can be sure of myself, leading to…
• Take a stand. Have an opinion. Defend my opinion until I have been convinced of my mistake, then admit my mistake and take up the opposite stand with equal vigor.
• Try a lot of things and don’t be afraid to make mistakes.
• Be quick to give credit and admit mistakes, both in public and in private.
• Recognize opportunity and follow up.
• Get down to the real “why” of something, whether it’s computer technology or another kind of technical discipline.
• Recognize the people, on the other hand, don’t always have a “why,” and learn to deal with it (I still work on that!).
• Always strive for quality over the quick and dirty.
• Concentrate on the things that I really want to do. I like to say “Only do those things that you can’t *not* do,” but in a down economy, I’ve learned to temper that with fiscal reality.
• Finish what I start.
• Make sure people are happy with my work and don’t stop ’til they are.
• Have balance in my life. I have a wife and children that I love and spend as much time with as possible.
• Horse trade. I am always willing to offer what I have, e.g. experience, time, contacts, etc, for what I want, e.g. work, money, content, etc.
• Help other people find their own places. I’m constantly concerned with my friends and their happiness and will do whatever I can to help them get to do whatever it is that they “can’t not do.” This is a lesson I learned from Don. He helped me to become all that I could be and, in turn, I do my best to help others.

Actually, most of this I learned from Don, either directly or indirectly. I guess my only real piece of advise is to try to find someone you admire and to do what they do. Don was my main mentor, but I’ve had many over the years and they’re invaluable, even if all I had was a beat-up six string…

Your friend and mine, Don Box, caused quite a stir yesterday with his keynote at European DevWeek in London. Peter Drayton has also written up a summary (which is much more technically meaty), as well as a commentary. There has been some quite spiriting follow up on this talk all over the Internet: the .NET mailing list, the Off Topic mailing list, the REST mailing list and XML Deviant on XML.COM. Also, while I absolutely agree with Don that the way we use HTTP today leads to trouble, I thought that Ian Griffiths, a fellow DevelopMentor instructor, had a wonderful point of view that he allowed me to share:

Guest opinion by Ian Griffiths

Basically Don seemed to be saying that there are two problems with HTTP (and saying HTTP is dead is just an effective way of getting people to listen; I was half tempted to start my Windows Forms speech at the UK MSDN DevCon with “The Web Application is Dead”).

One of these is that HTTP is unidirectional. Surely .NET remoting shows that this isn’t strictly true: individual connections are directional but it’s entirely possible to do callbacks by having connections go in both directions. (Well duh.) The real problem is that the firewall architectures of the internet are designed to make sure the connections only go in one direction; it’s not a problem with the protocol per se, it’s a problem with the infrastructure. In order to fix this problem you need to change the infrastructure regardless of what you do to the protocol. And if you fix the infrastructure you don’t actually need to fix the protocol, since we already know that it’s fine on networks that don’t deliberately break bidirectional communication.

Arguably one of the main obstacles here is the use of NAT - NAT makes it hard for a client behind a firewall to publish an endpoint. But NAT is fundamentally important because we’d have run out of IP addresses already if it weren’t in such widespread use. So the only way to get rid of NAT is for everyone to upgrade to IPv6. This will presumably happen fairly soon since we will run out of IP addresses in any case in about 3 or 4 years. (Windows XP ships with IPv6 support by the way. Type “ipv6 install” at a command prompt if you haven’t already. So Microsoft are quietly making IPv6 ubiquitous on the desktop.)

So presuming ipv6 takes off, that’s a fundamental technical obstacle to the one-way nature of HTTP removed. But another one remains: just because IPv6 pushes the address exhaustion date out of our lifetimes (we hope), doesn’t mean that firewall admins will let connections work both ways through the firewall. The bidirectional problem can only be solved with the blessing of firewall admins. And once you have that you don’t actually need IPv6, strictly speaking - given a suitable protocol between the client machines and the firewall there’s no reason that NAT can’t be done in both directions. (Indeed my sub-$100 firewall appliance can do this on a statically configured basis. It is possible (if a little inconvenient) for machines behind the firewall to publish endpoints successfully.)

UPnP apparently has a solution for this. (A better one than static configuration.) It supports P2P network applications that require clients behind the firewall to be able to accept incoming connections. It defines precisely what you need: a protocol that lets a client machine negotiate with the firewall to open up a port for incoming connections. So it turns out that a technical solution to the problem already exists. (Without even having to invoke IPv6. Although we still need that, due to a shortage of address bits in IPv4.)

So the first problem already has a technical solution. Presume for a moment (and it’s a big presumption) that these solutions can be deployed, and firewall admin policies set up so that they are broadly useable.

At this point, the second complaint Don makes - the fact that long-running requests don’t sit well with HTTP - becomes much less of an issue. We just need to use separate HTTP requests for the request and the response. We connect to the server, send a request, along with some response endpoint info (a URL). When the server is done it connects to us, sends us a response. And we’re done. I’m guessing it would probably be possible to write a .NET remoting channel that works like this. The only obstacle is the ability for clients to advertise endpoints.

So if a client can advertise an endpoint somehow (i.e. it can (a) convince the firewall to let a connection request come in, and (b) work out what the endpoint should be - it needs to be aware of any NAT translation going on) then HTTP can actually solve both the problems raised here. And as far as I can tell, *any* solution to the problems raised is going to have to allow the client to receive incoming requests. In which case why invent a new protocol? Once you’ve solved the fundamental problems in the network that stop you from doing this, HTTP is good enough.

The only issues are: (1) getting everyone to agree on how clients will expose endpoints (UPnP has had nothing but bad press so far, since the only thing most people know about it is that the first security hole discovered in Windows XP was connected to it somehow; so it might have to be something else…), and (2) convincing firewall admins to allow this functionality to be used.

Of course just because a technical solution exists doesn’t mean it’s a great solution. Given that this is a fair distance from HTTP as originally envisaged, it would doubtless be possible to design a protocol better suited to the job. But would the benefits be worth it? Everyone already has an HTTP stack and an XML parser - will they flock to implement a new purpose-built solution?

The problems raised in the ZDnet article can essentially be summed up thus: clients can’t expose endpoints. To me, this doesn’t look like a problem with HTTP, it’s a problem with the infrastructure. Changing the protocol is certainly not sufficient to fix the infrastructure problems; it’s not clear to me that it is even necessary.

So really this is a social problem, not a technical one. ;-)

If you’re interested in this topic or what other interesting things Don will say next, he’s giving the keynote address at the Web Services DevCon on March 21-22 in Beaverton, OR (10 minutes west of Portland).

I spent a fun two days up at Microsoft last week at the Visual Studio  .NET C++ Authors Summit, wherein the Microsoft team shows us how cool VS.NET is for C++ and browbeat us to write a book on the topic. Since I’m already planning to write ATL Internals, 2/e with Kirk Fertitta, I couldn’t talk them out of the XBox I so richly deserve. On top of that, they tortured me by taking me to the Microsoft store where they have XBox games for only $10! Those bastards…

If you’re a C++ programmer, VS.NET/VC7 brings a lot to the table. And according to Nick Hodapp, a PM on the VC team at Microsoft, many, many of you are C++ programmers. Microsoft quoted some 3rd party studies that say that there are about 3M C++ programmers out there (compared to 5M VB programmers and a whole lot less Java programmers). From a 3rd party survey of VC++ customers, Microsoft found that 90% (!) of them will be doing the same or more VC++ work in the future (about 22 hours/week). They also found that about 75% of VC++ users are MFC programmers (which isn’t growing) and 35% of them are ATL programmers (and is growing). Given the number of ATL7 books shipping right now or in progress (ours and a few more), and the increase in the audience, that made Kirk, my Addison-Wesley editor and me very, very happy.

Here are some other interesting tidbits from that survey for you:

• 68% of VC++ developers build client-server apps
• 61% build desktop apps
• 51% build peer-to-peer apps (This number slays me. What are these guys building?!?)
• 36% build embedded/CE apps
• 35% build NT services

While we were there, various members of the VC++ team attempted to rock our world in terms of the new and improved features VC7. Sometimes they succeeded. For example, Pranish Kumar told us how the ATL Server version of the Nile benchmark web application was 10% faster than the hand-turned ISAPI version in 1/4th the development time, which is why the Microsoft site uses it for some of their “through-put challenged” areas. Also, Terry Leeper showed us how make mini-dumps for VC++ projects that you can send to the developer’s who persist in saying “but it works on my machine…” He also showed us how you can pause threads during debugging, load symbols on demand, set breakpoints in DLLs that aren’t loaded at start-up (without that annoying dialog box) and just how much the new optimization features can speed up your code (they did an amazing demo with a recompiled Microsoft codedec that nearly doubled the frame rate with no code changes).

For those of you into ANSI compliance, Microsoft showed off an early internal build of their compiler that raises VC’s over all compliance rating to among the highest in the industry. They are able to compile all of the popular 3rd party template libraries, e.g. Loki, Boost, Blitz++, POOMA and a complete STL.

Tue, 12/18/01

During my three years as director of a software project, I learned a lot about people. In fact, I have a little text file entitled “My life as a dog” that may find a home on this site one day. However, because of a thread on the Windows Technical Off Topic list, one of the things I learned came roaring back like a bad acid trip.

The #1 problem with any organization is always communication. You can do postmortems on projects all day long and only #2 and above will be a surprise. The problem is that to build anything of any size, you need a team. As soon as you have to communicate what’s in your head to some number of other people, it’s going to happen imperfectly. The best way that we’ve been able to come up with to deal with this issue is hierarchical structures to practice selective information hiding, i.e. exactly the way we build software.

However, unlike software, humans have feelings and as soon as they perceive that somebody is hiding something from them, they resent it. Again and again, when I see information withheld to hide “bad” news, those being hidden from know something is up and they get upset. And when they’re upset, they send emails and IMs and phone calls around the company looking for every scrap of information they can find, all the while ignoring the work that suddenly seems a waste of time in the face of impending doom. The surprising thing is that when folks are given the truth openly and honestly, no matter how bad it is, they almost always dig in and deal with it. Just knowing that they’re trusted with the secrets of the company seems to boost morale.

I’m not saying that everyone needs to post their daily activities for everyone to see — that’s too much information. But I am saying that everyone from the CEO on down should be open about the issues they face, including being open to scrutiny and suggestions. I find that after doing that long enough, folks working for me tend to trust me to make the right decisions, leaving them to focus on their own work.

The key is that, unlike software systems where components have information hidden from them by their clients, humans can only be effective if they know that the information is available when they want it. Information hiding still needs to happen, but it’s humans that need to choose to hide information from themselves. It whole thing falls apart if the managers do the hiding.

Sat, 12/1/01

Effective C# is available now from Addison-Wesley. Of course, it’s called Effective Java, but *wow* the overlap is amazing. Some of his items I don’t agree with, e.g. return zero-length arrays instead of null (although I see his side) and others have been “fixed” due to advances in C#, e.g. override clone judiciously, but so much of it makes sense in C# (and .NET in general) that it’s scary. I feel like asking AW for the text so that I can port it to C# over the weekend. : )

Friday, 11/16/01

Last night, in the middle of .NET Band on the Runtime set, Don announced his retirement from DevelopMentor and training. He’s sorry to be leaving us, of course, as we are to lose him, but he’s excited about doing new things. Running a company gets more consuming as a company gets more successful and Don certainly brought DevelopMentor a great deal of success. And not only did he run his part of the company, but he also brought a amount of rigor and insight to an amazing range of technology topics, including C++, COM, DCOM, RPC, XML, Java and .NET, heretofore unprecedented in the training industry. He turned the phrase “them that can’t; teach” on its ear. But these are things that are well-known of Don.

What is perhaps not so well known is the care and dedication that he had for his friends and colleagues. He worked hard to turn his personal success into opportunities for the other technical staff members at DevelopMentor. And he succeeded. He paved the way for people like Ted Pattison, Keith Brown, Tim Ewald, Aaron Skonnard, Martin Gudgin and a host of others who’s made a name for themselves in this industry. Of course, I’m also on this list. If you look at the things that I’ve got listed on this site, i.e. books, articles, courses, conference talks, etc, a staggering amount of it was enabled either directly or indirectly by Don Box. He’s an amazing man and it’s been an honor and a privilege to work with him these last six years. They’re been the richest of my career and of my life. And for that, I’d like to thank him.

Before we get too blubbery, Don has assured the world that he will continue to pursue technology and to communicate it to an eager audience. I, for one, look forward to what he decides to do next. Whatever it is, I’m sure it will be uniquely Don.

Sun, 11/11/01

Many years ago when Java was new, I dove in. My first program I wrote like a C++ programmer and I didn’t get it. Then I rewrote the program as a Java program and it was much nicer, but I still didn’t get it. Then I discovered the lack of deterministic finalization and that’s all she wrote; my C++ thinking turned me away (the fact that Java was ashamed of my favorite platform and, in fact, all platforms didn’t help).

Now I’ve spent the last year doing .NET programming, mostly focused on Managed C++ and I didn’t get it. I’ve participated in DevelopMentor’s ASP.NET and Guerrilla .NET and loved both of them, but still didn’t get it. I rewrote (with my good friend Jon’s help) my entire web site in ASP.NET and didn’t get it. And I spent most of last week preparing for my teach of the latest version of DevelopMentor’s Essential .NET and I *still* didn’t get it. Until today. Today I finally got it. The major power of Java wasn’t that it was platform independent, as Sun so often touts. The power of Java (and therefore the power of .NET) is that it provides a major productivity boost for the programmer. I realized this today for the first time.

It started yesterday. Yesterday I ported a tiny little application (a time client) from MFC and C++ to .NET and C#. The first time I ported it, I ported it like it was still C++ and the result was ugly (I was trying to do the standard library trick of representing time as a the number of seconds since some marker time and then translating it into a formatted string at the last moment). In fact, I couldn’t even do the nice formatting of the current time since .NET didn’t support that means of conversion. But then I remembered that, unlike C++, .NET has proper date, time and span classes. Once I rewrote it in .NET style, it was a thing of beauty. With knowledge of only the name of the sockets namespace (System.Net), I was able to learn .NET and build a time client in under an hour. To paraphrase the closing sentence of one of my first articles, it just makes you want to grab the back the of computer monitor and feel the power of .NET.

Encouraged by my success and armed with the courage of my convictions (and a couple of web sites given me by Jason and Peter), I sat down to write a MSN Instant Messenger application. Those of you unlucky enough to have me as an IM contact saw me log in and log out about a hundred times yesterday (sorry : ). This was because every step of the way, I’d run my client and every step of the way, I’d make more progress. 90% of my code was reading and writing from the sockets and parsing strings. For the former, I used the StreamReader and StreamWriter and for the latter, I used the Regex class. Both did a ton of heavy lifting so I didn’t have to. It was amazing.

But yesterday, I still didn’t get it. I was so focused on getting my IM client working (about a half day’s work) that I completely missed the magnitude of what I was doing. I was implementing an async notification-based socket protocol after reading an example doc, skimming a spec and digging in. And the code I ended up with wasn’t spaghetti. It wasn’t production ready yet (my error handling, while present, was rudimentary) and I didn’t implement the entire spec, but I had refactored along the way and now I have the beginnings of a nice little namespace for doing IM work. And all of this happened the same day that I first discovered the existence of the System.Net namespace. It’s only after reflection (and a good night’s sleep) that I finally get it. The power of  .NET is the programmer productivity.

This productivity comes from a combination of ease of use and flexibility that’s going to attract almost everyone. It will attract the VB programmers because of the continued ease of use and the new functionality of the .NET Foundation Classes. It’s also going to attract the C++ and the Java programmers for the same reason, but they won’t admit that’s why they like it. They’ll claim to love .NET because of the power and flexibility. Not only are the .NET languages themselves allowed to be fully-featured, but the framework itself has tons of amazing functionality built right in. So much so that it’s easy to miss some of it. When I needed to calculate an MD5 hash in my IM client, I went to the net, downloaded some C++ code and built myself a COM object (although I could have easily built a MC++ component, too) and then brought it into my app via interop (see what not being ashamed of the platform can do? : ). That was great, but this morning Peter asked me why I hadn’t just used the MD5 functionality built into .NET. There’s so much stuff in there that I missed it. As a community, we’ll be digging into it for a long time to come.

In the past, I had scoffed at the value of programmer productive over user productivity. My argument was that programmers are soldiers on the field of combat taking bullets and protecting the users at home. This was how I justified the complexity of C++, but measured it against the flexibility of the language and the performance of the produced code, and therefore the pleasure of the user. Don’t get me wrong. We’re still going to be using C++ for high-performance, shrink-wrap software for some time to come. Windows and Office XQ (or whatever they’re going to call them) will still be implemented in C++. Client applications that cannot dictate their deployment environment, i.e. can’t dictate the presence of the .NET runtime, will still be implemented in C++ or VB6. Most of the rest is going to be built in .NET without 12-24 months. Stand-alone corporate applications can dictate the presence of the runtime, as can server-side n-tier applications. Web-based applications can take advantage of the compiled and caching performance gains using ASP-style programming, will still enjoying the flexibility and power of ISAPI-style programming via .NET modules and handlers. Everyone in these spaces that works under Windows is going to be moving to .NET, especially the Windows Java programmers who already know the power of such a platform, but want easy access to their DLLs and their COM servers. The reason that people in these environments can now afford to move is that continued research in virtual machine-style environments and increase in machine power has brought about the first platform where ease of use for the programmer does not mean that the user has to suffer. Applications built with .NET are going to be fast enough and when it comes to ASP, they’re going to be much faster than what we’ve had in the past.

The combination of ease of use for the home-by-5 style programmer and the flexibility for the computers-are-my-life style programmer was so great in Java that tens of thousands flooded the Java conferences from the first year. Mix in a user experience that doesn’t have to suffer from the programmers’ choice of  .NET and I finally get it.

Wednesday, 10/17/01

According to legend, the TA office next to the Stanford computer science lab is guarded by a teddy bear. Before a student is allowed to consume valuable time asking a question of the TA, they must first explain it to the teddy bear. Apparently the bear is able to answer 80% of the questions that students ask, saving time for the TAs to play Unreal Tournament.

I often feel like I act as the teddy bear for the COM community. I get several email messages a day from folks that consider the mailings lists (resources set up to answer just these kinds of questions) to be too slow, so they ask me directly. If I don’t know the answer off of the top of my head, I often respond with the following phrase:

    “Can you send me a tiny, tiny project that reproduces the problem? –Chris”

This, of course, implies that I will actually build and debug the project. And 20% of the time, I do. The other 80% of the time, by the time folks have reduced the problem enough to demonstrate it for me, they’ve already solved it, saving me the time (thank goodness).

Knowing that this is the case, I recommend that you become your own teddy bear. A whiteboard is handy for explaining the problem to yourself and Microsoft development tools are now so handy that you can typically whip out a small reproduction project very quickly. These very activities will often solve the problem, but even if they don’t, you’ve got a concise description of the problem and a small repro case to send to your friends or to post to the list.