March 26, 2004
Closed source, open tests
Chris Sells: "[Test driven development] lets Joe R. Programmer encode his assumptions as unit test code so that when I break his assumptions during an iteration of my API, I see it as part of my compiler output. This is huge. In fact, it's so huge, that MS should provide an end point for people to submit their own unit tests against our Windows and .NET APIs so that when we make breaking changes, we can either fix them or know the proportion of folks affected by this breaking change."
Many's the time we've been unable to work out from the documentation how API X behaves in Situation Y, and written a little test to figure out the behaviour. Since we then proceed on this "undocumented" information, it sure would be nice to be able to add it to the API developer's test suite. Who knows, we might even find out that somebody else has already done the research for us!
Next stop, being able to add it to the API documentation... oh wait, Vegas.
Small wishes for Whidbey
Okay, we're all looking forward to the mighty new features in Whidbey, but there are a few "small" features that I'd like to see in there.
First, I'd like the Start page to show the projects list in a proper MRU format. VS2002 got this right, but for some reason VS2003 shows them in the order in which the solution file was last modified. Sometimes I feel the urge to add and remove dummy projects just to bring the thing I'm working on to the top of the list. But that would be childish.
Second, I'd like to be able to turn off the namespaces in tooltips. If you're using a fairly deep namespace (Company.ProductFamily.Application.Class), particularly for the return type, the tooltip tends to take up so much of the screen it obscures what you're typing, and ends up being useless anyway because the argument list is squashed into a tiny column at the right hand side.
Small wishes, I know, but not every improvement has to be a mighty architectural feature...
So I ran FxCop and it said, "Change the enumeration name 'MetricData' to a plural form."
March 24, 2004
Developers still need books
Gunnar Kudrjavets: "It seems that reading books printed on paper may not be anymore the best way to measure how one keeps up with the professional skills."
It's certainly true that there is a lot of great information on the net, and that when new information breaks it breaks on the net. But I'd still consider books to be an important part of keeping up with professional skills. There are two reasons for this.
First, good books provide depth and context that a Web article or weblog post does not. The net is a great resource for understanding how to use API X. It's not a great resource for getting a comprehensive overview of the internal architecture of SQL Server. (It is a great resource for clarifying one's understanding of the internal architecture of SQL Server once one has got that overview though!) I have read a lot of great overview/architecture books from the comfort of my armchair that I could never have got through sitting at some horrible Web browser.
Second, books tend to address areas that the net does not. Again, the net is a great resource for technical information, but it is much weaker on subjects like project management, team formation, process etc. -- the "soft" side of software development. This is changing, and methodologies like XP evolved and remain well-documented on the Web; but on the whole I think the non-technical side of software development remains best represented on paper. And these are "professional skills" which are just as important as the technical ones.
So I would remain suspicious of someone who thought they were keeping their professional skills up to date just by monitoring Web sites and discussion forums. I'm not saying it can't be done, just that it's not necessarily the best way to gain a fully-rounded education. By the same token, with all the great info hitting the net, reading books alone is likely to be insufficient as well. A competent developer is one who refines and develops their professional skills by all appropriate means, whatever those means may be.
Pilgrim slays weblog politics; not many dead, but some gratifyingly nasty gashes
Mark Pilgrim demolishes the "blogosphere"'s predictable response to Typekey. I started picking out good bits to quote, but there were too many of them. It's a hoot. Go read it.
The power of the green light
Weiqi Gao: "The emotional power of the green light is greater than I thought."
I think this is one of the most powerful aspects of suites like xUnit. A report announcing "184 passes, 2 failures," although intellectually we know it's a problem, emotionally sounds "good enough" -- hey, it's a 99% pass rate, right? -- whereas a big red line announcing "You have failed" in stark visual terms connects viscerally and demands action. Dealing with affectless messages demands attentiveness and self-discipline; dealing with spectacular, absolutist failure is an emotional imperative.
So the IDEA feature where compilation status is colour-coded in the IDE sounds great. I'd much rather see this in Whidbey than the "unsaved/new code" colouring. The old hands may not get much out of it -- they've got the discipline to sort out even those last two level 4 warnings -- but for younger developers, those who need the more absolute judgments, it could make a real difference.
March 23, 2004
PowerPoint: 1% good
Tim Sneath: "My gut feeling is that most presenters rely far too heavily on PowerPoint slides as something of a comfort blanket."
The "PowerPoint: 99% bad" syndrome is an easy one to fall into, and Tim is right that canned slide decks can become a substitute for thought, knowledge and interaction. But it's also easy to overreact in the opposite direction when you're addressing a developer audience. Developers tend to bay for code, code, code, because code is concrete and slides are marketroid spin. Well, this is one case where presenters shouldn't give in to what their audience wants.
Yes, concrete code is important. But code alone only communicates the surface, and only at a limited set of loci. Seeing code helps the audience understand how they will interact with a feature, but not how that feature interacts with other features, what's going on behind the API, or how the feature set as a whole will fit together.
Now when you're dealing with a well-defined API feature, this is sufficient. If you want to show me how to use the shiny new authentication controls in Whidbey, show me code. But if you want me to understand the framework within which the authentication controls work, how I can back it on to my authentication system or what room it allows for customisation, show me pictures too.
Tim also resolves to go "off-piste" more often. "Rather than having everything slick and well-honed enough that there's no potential for digression or exploration," he says, "the fun comes when you are experimenting with things for the first time in front of an audience." Fun for the presenter, maybe, but not necessarily for the audience. Learning by trying things out is fine for some people, but (a) they'll do better trying things for themselves rather than watching you stumbling and (b) many people like to gain a strong framework of understanding before they are willing to dive in on their own. The "off-piste" approach is really great when it works, but all too often it goes wrong and then it's just awful. I still remember the toe-curling embarrassment of Chris Anderson's Avalon session at PDC 2003. How the audience cheered Chris when he switched off the PowerPoints and announced a code-heavy, "without a net" session. But he made a couple of early mistakes and never really recovered; as a result, the poor guy was made to look like he didn't know his stuff, and I learned very little about how Avalon apps fit together because we were too heads down trying to fix typing mistakes. I can't help but think that had Chris been able to say, "Oh well, that didn't work out, let's just talk for five minutes about (structural topic) then we'll come back to the code" he would have recovered a lot better and we would have all learned a lot more.
This isn't to say that Tim should follow the funicular tracks or that Chris Anderson should be chained to a PowerPoint deck as punishment for his sins. Absolutely not. But there's no harm in having something to fall back on, something that will bring you back to certain and solid ground long enough for you to catch your breath. Things do go wrong, and prepared material can help to mitigate the impact when they do. Plus the benefits of structure and higher-level exposition discussed above.
So let's not give in to the baying mob of "code, code, code" developers. Code is the bottom level, and it's a bad way to explain higher levels. As Tim says, there's no one hard and fast rule. Some subjects demand high-level exposition. Others demand low-level demonstration. Most demand a balance. Only you, the presenter, know. Don't let the audience lead you astray.
[I should add that none of this is aimed at Tim. I've never seen Tim present, but from the comments on his article he clearly already has the balance down pat. All ranting is intended as cautionary, not as any direct criticism.]
March 18, 2004
From Bangor to Baghdad
BBC News: "Expertise and support from Bangor University's Centre for Arid Zone studies will be used to help regenerate the academic standing of the Baghdad college as it undertakes environmental research."
Having studied briefly at Bangor and lived there for six years, I find it deeply ironic that such a place would have a Centre for Arid Zone Studies. Maybe the scientists were just desperate to find an excuse to get out of the rain.
Linux swearing in context
Plenty of occurrences of "crap," "shit" and "bastard" then, but I can't help but wonder how many of these occur next to the word "Microsoft"...
March 05, 2004
The stone age of computing
Tim O'Reilly: "As Jeff Bezos likes to say when exhorting his staff to innovate, 'It's still day one.' We're in the stone age of computing."
My friend Owen likes to compare contemporary computing to sailing in a hollowed-out log.