Nothing kicks off a conference like Krispy Creme doughnuts, Bill Gates, and models dressed as airline stewardesses.

Starting to wind down a bit now. Whidbey has had a few hiccups during this day of presentations but has also gotten lots of applause - particularly edit and continue, the hands off HTML designer (no code munging when you switch to designer view) - and the self contained web server (no more FPSE). Everyone anxious to get a copy of the latest bits tommorow. Tons of productivity improvements.

The coolest part of BillG's keynote (besides the commercial - hilarous) - was the overview of Speech Server. It's hard to believe integrating speech will be this easy.

Eric Lippert on stage now talking about talking about VSTO2.

Been a long day - but looking forward to the going to the ballpark tonight and chilling.

Getting Whidbey is great, but who do you have to sleep with to get a Yukon beta???

It is a little late to discuss leap years, since February 29th has already passed, but you never see what goes awry in any given leap year until after the magical date has passed.

CNN has an article about a leap year related glitch in the Pontiac Grand Prix. The display shows the wrong day of the week now, and the possible solutions range from resetting the software to completely replacing the display unit.

Have you ever wondered how many hours modern civilization has spent wrestling with the concept of a leap year? It’s the classic case of a business rule with a twist. Your unit tests look pretty simple when the analyst says “always place the order with the supplier who has the lowest price”. Then suddenly, almost as an afterthought, “oh, except on the last Friday of each month, then we need to place the order with the preferred supplier”. Suddenly, the test cases quadruple.

So in coming up with an estimate for hours lost to Leap Year, I thought of all the coders over the years in RPG, COBOL, Fortran, and assembly, and the myriad of languages where the leap year algorithm has been implemented time and time again by everyone from seasoned professional to college student.

Then consider the number of times a software leap year algorithm has been defective. We know older version of Lotus 1-2-3 and Excel both had the bug, but even new stuff like Grand Prix cars and personal video recorders appear to hiccup. Sometimes the leap year bug poses problems in obscure places (why is my Kerberos authentication failing this year?). Other times, just trying to deal with the quirky date in a thorough manner gives you unexpected side effects, like blogging software with only 29 days in January.

Working in .NET, we all know there is a static method on the System.DateTime class with the name IsLeapYear. Problem solved? Hardly – but the mention of DateTime keeps the post relevant to .NET.

Leap year isn’t just a software issue. Consider the company who pays salaried employees every Friday. Only this year, there are 53 Fridays in the year instead of the typical 52, an occurrence we won’t see again until 2032. As a well compensated CEO, you need to spend many hours with other executives to answer the following multiple choice question:

In order to reconcile the extra pay day in 2004, do we

a) Decrease the weekly pay of all salaried employees to compensate for the extra pay period, with a possible loss of moral.

b) Keep the weekly pay the same for all 53 weeks, in effect giving ~ 2% bonus.

c) Switch to bi-monthly paychecks.

d) Outsource all salaried employees below the VP level and sublease the office space.

Even PhD candidates sometimes forget about leap years, and this leads to increased global warming.

Finally, when considering an estimate, think of the 4.1 million people worldwide who have been born on Leap Day. Think of the hours they and their parents have agonized over when to celebrate the birthday during non leap years. Consider the poor fellow in Ann Arbor who was born on leap day, and carries a driver’s license that expired on February 29, 2003 – try entering that date into a rental car system.

So let’s make a rough estimate. 6 billion people in the world. On average, let’s say 15 minutes of each person’s life is devoted to resolving Leap Year issues. That’s roughly 170,000 hours the current population has lost. Not that we can really do anything about the situation, because changing the calendar usually requires an act from either the Pope or an emperor, so your local congressperson stands little chance. In software it will just be one of those business rules in the  “hard requirement” category.

It seems if I select a vertical block in the 2003 IDE (hold down the Alt key and select an area with the mouse), and then go to the Edit menu and select “Advanced” -> “Untabify Selection”, CPU usage for devenv.exe spikes and control never returns to the GUI. Easy to reproduce in any .cs file where tabs exist in the selected region.

If you are thinking of trying it – save everything first. Annoying, but easy to work around.

Update: Just tried this in the PDC Whidbey bits and there is still a problem.

Last night Ron Jacobs talked about Shadowfax to the CMAP user group in Columbia, MD. I enjoyed the presentation and found it informative. I think it’s great that people from Microsoft like Ron take the time to come to user groups and give these talks. Is it just my perception - or does no other technology circle get this type of community support?

Speaking of user groups, Geoff Snowman's blog is the place to see what events are happening in the mid-atlantic region.

There has been another flurry of postings lately regarding how technical publications should adapt to the blog frenzy. Specifically, Jason Mauss and Tejas Patel had some thought provoking posts.

I have a stack of technical magazines sitting beside my desk right now that I have not gotten to because I’d rather be reading blogs. I’m also a fan of constructive criticism, so I’m trying to go scan through the pile to see what I would do to make these magazines more appealing to me by listing what I do like.

First, Game Developer. The one highlight of every issue is the Postmortem, which will be written by someone inside a gaming company who just released new software. The postmortems will always list the top 5 things that went right and the top 5 things that went wrong, making it much more interesting than the fluffy case study that tells you how great your life can be if you were just using tool XYZ. There is a level of candidness here that generally never makes it into other print articles, but certainly makes it into blogs. There is also a level of human interest, as you can read about conflicts between different stakeholders and how they were resolved. How did they approach bug fixes? How close to the wire did the project go? What features did they have to drop and how did they prioritize them? How did the build process work? Even though it’s the game industry, it’s still software development and the issues are real and I learn from them.

Embedded Systems Programming. Every month Jack G. Ganssle has a column at the end of the issue. Jack has been around the block and is interesting because he tells stories when he writes. Sometimes the column is technical, sometimes not, but it is always down to earth and never pulls punches. This month it looks like he will tell developers how to explain to their managers the ROI on an investment in new tools – something we all need to do at some point.

Dr. Dobb’s Journal. I like Dr. Dobb’s because it contains such a diverse range of content. The April cover looks interesting because it covers everything from data mining, to developing USB device drivers, to adventures in palindromes – which sounds interesting. Also, Michael Swaine writes intellectually stimulating prose every month. This is comparable to the blog world, which contains lots of diversity and often gives you something to chew on with the brain for a bit.

Software Development magazine is generally interesting. It’s different because it is touching on topics like management, design, process, interviews, and other touchy feely subjects not covered in other technical publications. These topics are admittedly difficult to cover without sounding like theory from a college text book – so I wish they could do some more down to earth practical advice, perhaps some interviews and case studies from teams who are doing aspect oriented programming or extreme programming and let us know what went right and wrong.

So after a bit of review, I’d say there are three things technical publications could do to increase their appeal (to me, at least).

First: be real. Tell stories. There is more to creating software than cookie cutter solutions. These stories come out in blogs and they are interesting. Interview developers - tell us what it is like to work at Oracle, or any company from a startup to an industry leader.

Second: Stop trying to stir up controversy on topics like “C# versus VB”. In newsgroups we call this trolling. Also, the editorials on well trodden subjects like offshoring are completely uninteresting unless you have something original to say.

Finally: Look for more diversity in the topics and make some thought provoking topics. Some publications just seem to repeat themselves every three months with slight variation. Performance tips for ADO.NET, Using XML Web Services, yawn, yawn, yawn. Don’t cater to the lowest common denominator and give us something to think about when we are done reading. I want to know what books I could read that do not have .NET in the title that can help me professionally.

So now, it's late, and I still wont get to these magazines.

I had an interesting experience this week with a client using Analysis Services. They have an OLAP cube which holds all the transactions at a hospital for the past 3 years. There are 35 million records to keep track of every $3200 pacemaker and $3 aspirin tablet used.

The cube reprocesses on schedule every weekend – this typically takes less than 8 hours. This week the cube had not refreshed and I had an email asking to investigate. I logged in over a VPN and saw the SELECT statement from Analysis Services was still going strong after 52 hours. Not good!

First we checked current activity to see if any SPIDs were blocked - no. Any other extraordinary activity on the servers? No. As the plot thickened, I decided to look at the estimated query plan for the OLAP SELECT statement in Query Analyzer.

The cube has 8 date dimensions, meaning 8 joins to a date dimension table that yields the fiscal quarters and calendar quarters and other date attributes analysts love to use when producing trendy charts for board meetings. The estimated query plan showed SQL Server was thinking each join would double the size of the resultset. By the time all the joins are complete SQL estimates there will be almost 9 billion rows instead of the 35 million there should be.

I’m making a wild guess that when SQL Server thinks it needs to process 9 billion rows it figures 2GB of RAM won’t cut it and goes straight to the hard drive. Even though the query wasn’t producing 9 billion records – it was certainly taking a long time and not using much CPU.

I immediately thought this had to do with indexes or index statistics. I looked at the indexes on the date dimension table. The clustered index was on the column used in the 8 joins. I realized the column was not the primary key column but did hold unique date values – one row for each day over a 20 year span. Unfortunately, nobody told SQL Server the values were unique. Just adding a unique constraint put everything back to normal- the query plan looked better and processing finished in 8 hours.

The moral of the story is: proper design can also yield better performance. The more you can tell SQL Server about the data the less it has to guess and prepare for worst case scenarios.

Driving home the other day I was thinking about various snippets of recent conversation over Yukon. One underlying theme is the question: Will developers go crazy with the CLR integration and hang themselves? String and array manipulation will be much easier, but the ability to throw blocking I/O statements into stored procedures is a sobering thought.

I started to do some googling to see what has turned up in the other database circles where JVM hosting has been around for a few years. It appears there are not too many complaints, and hardly any “best practice” documents to address performance related problems when mixing SQL and Java in the database.

I don’t think this sets a precedence, however. The J2EE camp often avoids stored procedures because they don't port to other platforms easily. In contrast, Microsoft has long advocated the use of stored procedures as good practice for performance and security, and as a layer of abstraction. Also, (and this section is based on my experience and may bear no relation to reality), the J2EE teams are generally bigger and have a dedicated DBA who keeps procedural thinkers from mucking up the prize jewel. At some companies the DBAs even carry small taser pistols so they can incapacitate developers who start tinkering in SQL code.

In any case, it should be interesting to see what turns up in the forums and message boards when Yukon goes live. You always have the people who say “Doc, it hurts when I do this”. Answer: “Then stop doing that!”.