You've reached the internet home of Chris Sells, who has a long history as a contributing member of the Windows developer community. He enjoys long walks on the beach and various computer technologies.
Saturday, Jun 22, 2002, 12:00 AM in The Spout
Object vs. XML
I was watching a group of folks present a new XML standard the other day and I realized something for the first time: to XML folk, OO languages are just script-like "glue" for connecting XML processing steps, the "Unix pipe" of the new millennium, if you will. Integration with OO languages is necessary to enable XML dominance, but that's an accident of history. In the view of the XML zealot, OO will eventually fall away and only pure, clean XML will be left in its place.
As an OO guy, I find this view disturbing. As a general technology wonk who sees the value of XML, I find this view unrealistic. Just so you XML folks know, OO guys look at XML as a data transfer syntax and that's all. OO guys are happy that XML is there, but they prefer to stay away from it in favor of their nice, familiar OO environment.
The problem, of course, is that many XML guys are so steeped in the new world that they forget where they came from. To paraphrase the Matrix, XML guys don't even see the angle brackets anymore -- they just see blonde, brunette, redhead. OO guys, of course, *only* see the angle brackets and prefer their artificial world-like simulation.
The result of this massive gap between XML and OO folks is that the great thing that the XML guys are building, i.e. a general-purpose hierarchical data manipulation, transformation and interoperation infrastructure, something that OO guys desperately need, is being lost because the two groups don't know how to communicate with each other.
So, to enable XML to dominate, XML folks have to be sneaky. Just like OO finally took off in C++ when it provided a super-set of the procedural programming in C, XML has to provide a super-set of OO programming, down to the easy syntax and the compile-time type checking. Only when you give the OO guys exactly what they already have can they begin to see what new things you've given them.
Wednesday, Jun 12, 2002, 12:00 AM in The Spout
Karma
While I definitely do have faith that there is a higher power in the universe (although I haven't yet decided if the universe is a good place to be or if it's just a simulation solving some higher level non-deterministic finite state automata), I'm not a religious man. If fact, I consider myself a completely recovered Catholic (I've been clean and sober for more than a decade and I never feel the need to go back for another hit off the body of Christ) [1].
Likewise, I'm not a superstitious man. I understand that going under a ladder may cause pain if something drops on me, but not for some other mystical reason. Similarly, breaking mirrors could cut you, but only the most serious of cuts could last for 7 years.
Still and all, I do believe in karma, otherwise stated as "what goes around, comes around." It's happened many times in my life that a lot of bad luck eventually yields to a lot of good luck. Likewise, when you do bad, bad comes back at you and when you do good, good comes back. Of course, these phenomenon can be explained by statistics and human nature respectively, but I prefer to think of a giant celestial scoreboard that I can affect by doing good for people. Or, and this happened just today, if I do something to cause harm, even if there's nothing I can do to make it up to the person involved, I often find myself feeling better if I do something good for someone completely different. Oh, wait, maybe I am superstitious... Still, I find it a comforting way to run my life, so I'm going to stick with it. : )
[1] I've known practicing Catholics that are offended by the idea that Catholicism is a disease to be recovered from. Sorry.
Tuesday, Jun 11, 2002, 12:00 AM in The Spout
Adding Ref-Counting to Rotor
Microsoft has granted Sells Brothers, Inc. a research grant to add ref-counting to Rotor and to study the performance effects. The proposal that lead to that grant is available here. There's been a lot of speculation about just how we're planning to add ref-counting to Rotor. Here are the highlights:
- It's not just "me," it's "we." I've already have very useful input
from several folks, including Jason Whittington, Ted Neward, Ian
Griffiths, Serge Lidin, Craig Andera and Bill Conroy. Also, Chris
Tavares will be spending most of July doing the actual implementation.
If anyone else wants to dig in, feel free! I'm happy for the help and
anyone that provides insight will get credit.
- The goal of adding ref-counting to Rotor is to measure the
performance effects of a deterministic finalization-like model that we
gave up when moving from COM/C++/VB6 to .NET. I say "DF-like" because
we're not getting DF, because the price of determinism is that
sometimes an object is never finalized, e.g. cycles. We can do better.
- We will not be replacing the existing GC's ref-tracking. It does a
fabulous job managing memory and managing cycles and we won't touch
that.
- The ref-counting implementation's sole job will be to call an
object's finalizer ASAP. Note that this is in no way "deterministic."
Plain ref-counting is deterministic in that it calls an object's
finalizer just as soon as there were no more outstanding object
references. Cycles meant that this would never happen
(deterministically). A hybrid ref-counting/ref-tracking system
improves "never" to "eventually" in the case of a cycle and maintains
the ref-counting's guarantee for ASAP in their absence.
- Even objects that don't have finalizers will need ref-counts, as
they maintain references to objects that have finalizers (and so on).
- Value types will not need reference counts, but when they go out
of scope, there will need to be a Release on any object references the
value objects contain.
- When the GC kicks in and finally breaks a cycle, it would be nice
to release all objects held by the cyclic objects so that they could
return to normal ref-counting determinism. However, since we've
already blown determinism by being in a cycle, this seems unlikely to
be very helpful. Also, by skipping this we can keep all of our changes
in the JITter and out of the GC, which simplifies the initial
implementation.
- We'd plan on adding ref-counting at the runtime level in the
JITter so that all languages gain the benefits w/o updating the
compilers (or mandating anything special in any language). The real
work is figuring out which IL instructions require AddRef/Release
calls and getting those calls into the instruction stream. Because of
this, we're not likely to be able to handle tail calls (at least,
initially). Anyone with advise in this area would be welcomed with
open arms.
- We plan on working nicely with existing IDispose-based code. Since
our ref-counting is all about calling the finalizer, if the ref-count
gets to zero and there is no finalizer to call, no finalizer will be
called. That means that Dispose implementations that call
GC.SuppressFinalize will not cause any problems with the ref-counter.
Of course, the goal is that the IDisposable.Dispose protocol is not
necessary at all.
- As a potential optimization, I have found a nice place to store a 7-bit ref-count in the existing space allocated to every object, so there will be no space overhead, only CPU overhead. However, this narrows the number of objects per process with synch blocks and/or hash values from 134 million to 1 million. It also narrows the number of referencing objects from the traditional 4 billion to 127. Anecdotally, 127 seems like enough, but it will necessitate the need to abandon ref-counting on any object that reaches 127 extent references. Since most data structures where more than 127 references could happen are parent-child, e.g. every child in a tree with a reference to the root, and this indicates a cycle that can't be handled by the ref-counting anyway, turning these objects over to the ref-tracking portion of the algorithm seems reasonable. However, we won't know 'til we look how many object references an object is going to have, so we'll track maximum reference counts during our tests to see if this optimization makes sense at all.
Sunday, May 26, 2002, 12:00 AM in The Spout
The Truth Is Not Enough
Watching the final episode of the X-Files, I realized why I don't like that show. Mulder spends all his time searching for the truth, but even when he finds the date of the planned alien invasion, he doesn't do anything with it! They've spent the last nine years discovering the truth and not doing anything to change it (or, if they do try, they fail miserably). Of course, that's not the only problem with the show (e.g. why would an alien race powerful enough to do generic engineering to produce the "miracle child" or to create "super soldiers" or to create the virus in the first place, needs to bother with setting up a shadow government), but it's the one that bothers me the most.
Just knowing the truth is not enough. You need to act on it.
I don't really know what that's got to do with the price of tea in China, but hey, you get what you pay for. : )
Friday, May 10, 2002, 12:00 AM in The Spout
Now the Fun Begins
Last night at 4:46pm, Sara Williams announced the availability of Microsoft's 4+ years of labor: the Microsoft .NET Framework, v1.0. And then, at 5:59pm, the great land rush to download the matching VS.NET bits began. Here are some links you may find interesting as you move to the RTM of .NET and VS.NET:
Here are some fun facts for you:
- The compressed VS.NET Enterprise Architect download is 1.8GB and it took my puny cable model 4+ hours to download.
- It took my laptop (574MHz, 512MB RAM) 30+ minutes to unzip.
- The resulting pre-installed folder was 2.45GB.
- The .NET runtime build number is 3705.
- The VS.NET build number is 9466.
- The codename for .NET was "Lightning" (hence the ildasm icon).
- The codename for C# was "Cool" (hence the "C# is Cool" t-shirt).
- Mike
Woodring's most excellent
asmstats
tool reveals the following:
Done processing c:\windows\microsoft.net\Framework\v1.0.3705.
Processed 69 assemblies comprising 70 modules.
Types: 8,866 (of any kind)
Classes: 5,602 (2,183 public)
Attributes: 297 (257 public)
Delegates: 334 (213 public)
Interfaces: 983 (659 public)
Enums: 1,085 (710 public)
Value types: 565 (121 public)
Members: 414,990 (of any kind, instance and static)
Methods: 281,630 instance, 12,797 static
Events: 13,160 instance, 24 static
Properties: 44,689 instance, 1,233 static
Fields: 28,478 instance, 32,979 static
Congrats to the Microsoft .NET team for a job well done!
Thursday, May 9, 2002, 12:00 AM in The Spout
For the Love of the Story
It's only happened a few times in my entire life, but I want it to happen more. It's that feeling you get when you're telling a story, trying to describe a scene or a technology or a something and, suddenly, without warning, it starts to tell you. It happened twice in college in a creative writing assignment: one of those times it actually gripped me from the moment I started writing my life story on a 3x5 card (I remember it started "I was an accident." : ). It happened once while writing ATL Internals: Chapter 7, Collections and Enumerations. And it just happened again while finishing up a writer's journal entry I started yesterday:
Whack-thump-thump. Whack-thump-thump. The sound filled the first floor. Whack-thump-thump. Tom knew he wasnt supposed to play ball in the house. Whack-thump-thump. His father, watching from the kitchen, had laid down that law several times when things had gotten out of hand. Whack-thump-thump. The ball continued hitting his hand, the floor and the door in the never-never land between the kitchen and the front entry. Whack-thump-thump. Tom, at 6, seemed to be using the mesmeric sounds to enter another place, somewhere regular, somewhere safe, somewhere comfortable. He had always been able to enter that place, whether he was playing with action figures, with clay or even with ordinary items like pencils or popsicle sticks, using them in the theater taking place in his head. Whack-thump-thump. Whack-thump-thump. His father was a much more literal thinker. He was creative, but creative in an engineering/problem-solving way and he envied his sons ability to enter this world seemingly effortlessly, never getting bored when the ordinary world around him failed to offer what was safe and regular and comfortable. Whack-thump-thump. Whack-thump-thump.
I started writing this to describe what my son Tom was doing yesterday morning just before school and it turned into a look into how much I loved and admired my 6-year-old son. He's so much different than me, but just like his mother and looking at him makes me realize just how much I love my wife. That's what writing is supposed to do. It's supposed to help you reach into your self and share what you've got with others. That's what this blog is all about and I appreciate you being here to listen.
Wednesday, Mar 13, 2002, 12:00 AM in The Spout
This is Not a Blog
Web Logging (blogging) is the wave of the future. Blogging is re-making the internet. Blogging is journalism where everyone is the journalist. Blogging is all that and a bag of donuts.
OK. I guess so. I like blogs. I read a bunch of blogs. But most bloggers feel like they have to update their site at least once/day and most do it far more than that. Because of this, their blog entries end up looking like this:
[burb] Excuse me.
It's not that I don't love to read a daily blow-by-blow of these peoples' lives... oh, wait, no, it is that. Maybe a little filtering would be handy?
And while we're on to the filtering thing, maybe we could drop the meta-comments about blogging itself? How cool could blogging really be if every other entry is about the power of blogging itself or, even worse, a link to somebody who linked to your cool description of the power of blogging?!?
Anyway, the spout is not a blog. I only update it when I think I've got something interesting to say (even if it's something that only I'm likely to think is interesting), I don't use any content management software (unless you count ASP.NET and FrontPage : ) and, except for this entry, I don't spend any time talking about the wonder of blogging itself.
Wednesday, Feb 27, 2002, 12:00 AM in The Spout
How Did You Get Your Start?
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...
Wednesday, Feb 27, 2002, 12:00 AM in The Spout
Please Say "Why"
As .NET demands new books and articles and the economy has given a lot of smart folk free time, the world is becoming inundated in .NET books, articles, talks and courses, many of which I am tapped to review. Some are wonderful. Some are awful. Most, however are *almost* good, the path to goodness well within the author's reach but for the answer to one question: "why?"
Most of my feedback is riddled with questions that start with why: "Why was it built this way?" "Why are there three choices and how do I choose?" "Why should I care?" Please, when you write, remember this question and answer it thoroughly and well. The why is *so* much more important than the how. The online documentation for .NET is fabulous for describing the how, once you understand the motivation for this class, that method or the other namespace.
Prose that provides the how is transient, but prose that provides the why becomes classic because the why itself is surprisingly applicable between technologies. At the very least, if you answer the why, it will save me work if I'm to review your prose.
Wednesday, Feb 27, 2002, 12:00 AM in The Spout
HTTP is Dead?
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).
Tuesday, Jan 22, 2002, 12:00 AM in The Spout
A Visit with the Visual C++ Team
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.
Tuesday, Dec 18, 2001, 12:00 AM in The Spout
Too Many Secrets
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.
Saturday, Dec 1, 2001, 12:00 AM in The Spout
Effective C# Available Today
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, Nov 16, 2001, 12:00 AM in The Spout
Thank You, Don Box
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.
Sunday, Nov 11, 2001, 12:00 AM in The Spout
If you knew .NET like I know .NET...
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.