TechEd: Something new, Something old

I am in Orlando, FL at TechEd. I have not attended that many TechEd conferences in my career; I was mostly a PDC bigot. I think this is my third or forth TechEd conference. There is another guy from my division here who is all of about 25 years old and I can’t help but notice the difference in how we approach the conference. The first thing of note is where each of us is at this moment – about 10pm on Monday night.

I am in my hotel room typing this entry and getting ready for bed. He is out partaking of the different events being sponsored by Microsoft and/or the different vendors here at the conference. I think I heard that there are things going until 1am tonight. There was a time when I would be out until the wee hours, stumble back into my hotel room for a couple hours of sleep and a shower and make the first session of the morning. On more than one occasion I was still a little (OK allot) intoxicated in that first session I have this image that my colleague is doing just that – but I don’t want to incriminate him .

Ahhh, youth.

I tend to go to sessions that fall into one of two categories; either ones on topics that I know very little about or where I want network with the presenter and/or other attendees. My expectation is that any detail I see here I will have forgotten by the time I leave. So I am just trying to get the gist of something. My colleague, on the other hand, seems to be focusing on WPF in hopes that he learns enough to start using it when he returns to the office. Part of the rationale I think is that I have to bring big concepts together and understand paradigm changes; whereas he needs to just bang out code.

Lastly, the food. I just can’t eat that conference food anymore. I am convinced that it’s the reason I ended up sleeping through a couple post lunch presentations. I realize that may be hard to believe after reading that I was still blitzed at breakfast. I have experimented enough with the permutations of this enough to know that the food was certainly the nail in the coffin. I think at 25 I could eat just about anything. Now 15 years later, it’s another story altogether. I think there should be a special dietary line for guys like me – I don’t know what to call it but I know what it would look like. Hey I know what you’re thinking – not it’s not a can of Ensure. It is much lighter; less pasta and meat more vegi’s and sustaining foods; you get the picture.

Anyway, times have certainly changed – at least for me. Maybe I can find the retirement room.

Annoyed with MSDN Magazine

My reading habits around MSDN magazine changed recently and now I am back to getting the print version of the magazine - I have a complaint about the cover. For the past couple of years I have been trying to exclusively read MSDN magazine online and so I let the print subscription expire. Well that was just not working for me since I rarely read an MSDN article in one sitting. So I turned my print subscription on and I have a small bone to pick. But first a little more back-story.

As the number of products and technologies available to build applications has grown I have found that I can no longer be an expert in everything. Rather I have had to focus my depth on a few technologies and be at the 100/200 level on the remaining ones. You might be scratching your head going “then why is the depth of MSDN magazine a problem?” Simply because the intersection of what I am going deep on and articles in MSDN is smaller [which, by the way, is exactly what it feels like the editors are striving for and is a good thing]. So my typical MSDN experience is reading 1, maybe 2 articles in depth and skimming the rest.

Well that is not exactly my typical MSDN experience; which brings me to why I feel like venting a little today. In actuality, the first thing I do when I get any magazine is to rip out all the marking stuff. You know the stuff I am talking about all those things from vendors and subscription blow-ins. I hate them because I can't flip through the pages without stopping on one of these. They are like bookmarks someone else put in a book - they are never what I am looking for. Only after removing all these obstructions do I feel that I can actually absorb the content.


Well, this is the second month I have noticed a new cover style for MSDN – the cover that folds back over the outside. It has been my experience that on most magazine covers when the fold-out that the fold out actually tucks into the magazine. Given my routine of cleaning up my magazines before I read them I would open the front cover, flip open the fold-out and see if it was anything interesting. Why a fold-out? Sometimes I have been rewarded with some nice panoramic nature scene and I don’t mind so much. But I digress…regardless my next step is to rip off the fold-out part.

In comes MSDN with the fold-out cover that folds outward; back across the front of the magazine. So in this case if I rip off the fold-out part then I am removing the cover of the magazine. For MSDN, more than other magazines I get this is unacceptable since I use the cover to find articles I want. So I left the cover the way it was.

Here is the problem; once I open the darn thing now the cover becomes an absolute annoyance. It keeps getting caught on things. Torn. Battered and otherwise abused. Which leaves me no other solution then to rip off the fold-out (and be left with this faceless magazine) or to just toss the magazine [hey I used to be the kind of guy who would buy a new car when the windshield wipers needed to be changed].

This leads me to one of two conclusions; either the folks at Microsoft have been spying on me in my favorite reading location (very gross). Or I am not the only one that has this cleanup ritual (almost as scary).

Or it could be I just needed something to write about. I don't have much time before my next meeting so this is best I could do on short notice. Don't worry I am not loosing any sleep over this one.

A Win is a Win

A win is a win is a close cousin to the win–win outcome. Recently at my place of work (which I cannot publicly identify here – suffice it to say its corporate America / Fortune 100) I had to compromise in order to achieve the high level goal and objectives; but not via the implementation originally planned. Just thought I would share this experience since it served as a profound reminder to me on the importance of meeting the goal/objective and not being too close to the implementation details. This is something I am personally struggling with lately as I find myself envisioning more and implementing less.

In this particular case it was around a code generator we have written to generate all the store procedures and data access code for .NET applications. For a number of reasons we ended up with two implementations that from a high level did the same thing. Each had features the other did not have. Since I am on the Architectural team I was really driving my implementation since it address more of the shared scenarios needed by the developers. The problem was that who was going to maintain this implementation? I could not, I have other fish to fry and need this initiative to be owned more by those who will be using it. It became apparent to me that this was just not going to happen; the reasons range from the “not grown here” mentality of developers to the general lack of understanding of what the tool did.

So in order to evolve the tool and to enable it to evolve; I had to make the hard decision to use the other code base. This was more of an ego thing than anything else. So once I was able to get over that the move was absolutely perfect. We are now going to have one of our top developers working on this key part of our development tools and I will be providing some high level guidance.

The reason this is not a win-win; even though it may seem so up until this point…We spent a bunch of money working on both of these tools. Most of the work on each tool was done by consultants; one who is very expensive and the other who is moderately expensive. Now I struggle with the age old problem of what happens when the consultant leaves or we decide we can't afford him anymore; which has already happened to one of the consultants.

What are you doing, right now?

I am having one of those ornery moments and I am taking it out on Outlook. It locked my machine up hard today and I don’t know why; which really burns my toast.

I was just scanning through the boatload of emails in Outlook 2007 and noticed an orange status bar continuously scanning on the To-Do Bar. Here is what starts running through my mind...

"I appreciate you showing me that something is happening; but can you throw me a bone...What the are you doing? Did you ever consider that maybe I want you to stop?"

So I set out to try and figure out what Outlook was doing; the way a non-developer may...

I tried hovering over the area – nothing.
I tried clicking – nothing.
I tried right clicking – nothing.
I asked the help system – nothing (don’t get me started).
I asked Google – nothing (could not form narrow enough query).

So what else can I do but to just rant on my blog about it. Wouldn’t you know it; I soon as I went to grab a screen shot – it stopped. So I took the screen shot anyway and circled the place where this happening. On the off chance that someone actually reads this AND they know what the heck that bar means; please let me know.

I think Microsoft has done a better job at reducing the number of pauses that happen in the software; where things just stop and have you wait for some “background” process to complete. It is my opinion (and we all know how many of these there are and what they’re worth) that it would be better to just tell the user what is going on; it’s the not knowing that makes it hard.

For instance, when I delete a file in Windows why does it take so long? What would be nice is if Windows told me in the status box…

"Please wait while I put this file in the recycle bin for you"
"Oh, this is taking longer than I expected because someone else is hogging up the disk channel"

[Note: Of course I hope that for the sake of my Mom that they would clean up the message a little; I can just imagine trying to explain that message to her (unlike Don Box's mom, my Mom does not know assembler).] Now that I know why I have to wait maybe there is something I can do about it – “Oh yeah, I started that Disk Cleanup utility a couple of minutes ago, maybe I should pause it”. Users will start to draw correlations between things and just become smarter.

Conceptually what I am describing sound nice; but as a software guy this pretty challenging. It seems like it requires design/architecture that supports the exchange of this type of information. Of course security would have to be honored. Not to mention that you may end up telling people more about the internals of what you are doing (or not doing) than you would like to. This would make a good thing to report on when capturing data around user experience, which Microsoft (and others) seem to be doing more of.

Sometimes I wish I was working on something this cool.

Quotes

Just a thought it would be prudent to give credit for the name of my blog; this phrase was uttered by my good friend Bernie Odoy.

We were feeling pretty punchy one day and were just amazed that how sometimes what we say does not seem to have any impact on those it was said to. Does this happen to anyone else or is it just us? So in a moment of extreme sarcasm Bernie uttered this quote – Sometimes words mean something. I realized its brilliance immediately and wrote it down on a post-it and stuck it to my monitor. That was two employers and 4 years ago.

Here are some of my other favorite quotes on my board of fame. No one famous; just a bunch of people I have worked with over the years and maybe one or two of my own (I have no idea where this is going).

“If you say something and no one hears you. Did you really say anything?” This too was uttered by Bernie. I am not sure that it was said on the same day as the previous quote, but certainly has the same sentiment.

“It’s either Wrox or it’s Box”. This is a quote by yours truly. I used to teach a lot of classes and this one was uttered in response to a question an attendee asked me. They asked me what the difference is between the two books – a book published by Wrox (a technical publisher) or another book (I don’t remember the titles and that’s probably a good thing to protect the guilty). At the time I was not a big fan of books published by Wrox; nothing personal, but they just seemed to be a book factory and the quality suffered because of that. So I was comparing a book published by Wrox to a book written by someone else who was all about quality - Don Box. Don is this really cool down to earth dude who also happens to be really smart and articulate - leathal combination. Don had a way of presenting information with layers; so no matter your “level” you would walk away with something. That takes skill and time; two things that you don’t get when you are rushing a book to market. So I was trying to say that either you get something quick or you get quality. Hmmm, I seem to recall telling some project managers I have worked with in the past the same thing…

“…It’s still a collection; it’s just that it’s a collection of one”. My good friend Greg Manto gets credit for this one. At the time we were working at Microsoft (as consultants) and Greg, Bernie and I were all on the same engagement together. We were building this object model for our client written entirely in VB4. Yikes! We were in a design meeting discussing how to implment this one class and Greg uttered this quote. He did not mean to imply that everything is a collection, but rather that just because you only have one does not mean that it is NOT a collection. He went on to say that if there is a good chance that there will be more than one in the future make it a collection today; so that the object model does not need to be changed to accomodate this in the future. You can use defaults and shortcut properties to make getting to the most common element in a collection easy. It is something that has stuck with me ever since and I get a chuckle every time pull it out of the archives.

I realize these are never going to make to the quote hall of fame; but they were uttered by some code warriors in the heat of battle. In my book, that makes them pretty good.

By the way, I still have the original post-it.

Back in the saddle again

After a long hiatus from blogging I have decided to get back online. I feel like there is plenty to comment on regardless of whether anyone is listening or not.

On a professional note; I just had to cancel a vacation in order to debug a performance problem at work. It is one of those particularly gnarley problems that does not occur regularly. It is always interesting to get back into the mindset of solving performance problems. They require an extreme amount of rigor and analysis. It's a different mindset than pure development.

I find then when developing I will often change several things at once and then re-run my code testing each of my changes. Typically the changes I make are independent of one another; that is I don't try and fix the same thing more than one way. It reminds me of a couple of core tenets of debugging these types of problems…

1. Jim McCarthy (formally of the VC++ team) has a principle from his book that states – get to known state and stay there. This is paramount to trying to solve these types of issues. You can’t introduce change into something that is not stable.

2. Change one variable at a time. Measure. Correlate. Confirm. Consider changing another variable. We had someone change two things in the environment and the problem disappeared. It’s bad enough it happens sporadically, but now we cannot attribute the disappearance to any one thing.

3. Get to a simple reproducible case as soon as possible. In our case it takes us three hours to recreate the problem – IF (big if) it’s going to happen again. That means we only get 2-3 attempts per working day. We are pretty close to getting that down to an 18 minute case; which means we spend much more time working (not waiting).

Time to get back to running tests rather than writing about them.