#pragma-tech

Moving On

noreply@blogger.com (Scott Walker) — Mon, 20 Sep 2010 18:58:00 +0000

Not that many people probably read this blog (which is no fault but my own) but for anyone that still does I thought I'd let you know that I'm moving on.

You see I'm starting my own Rails firm called ProtectedMethod here in Columbus. Therefore any future blog posts I write will be posted on the company blog here.

Learning The Dark Arts of Debugging

noreply@blogger.com (Scott Walker) — Fri, 23 Apr 2010 16:55:00 +0000

Several months ago I had the opportunity to record an episode of

with Chris Woodruff and Keith Elder. The idea for the podcast started way back at Devlink 2009 where I ran into Keith at the speaker's VIP dinner. We'd both had a couple of drinks by that time and got to chatting about a lot of different subjects, one of which was the talk I was giving at the conference about production debugging. Keith thought it sounded like an interesting and relevant topic that they hadn't had on the show before so we struck a deal to get an episode recorded.

I put quite a bit of time and effort into synthesizing some of the most important information into a form I thought I could talk about over the phone. Even with all that prep work though I must say I was still pretty nervous on the night of the actual recording. I feel like at this point I'm pretty good in front of a crowd giving the talk when I've got slides and examples to show. I found out that trying to explain it all with just words can be a much more difficult endeavor!

All that aside though I think the end result turned out quite well. Probably thanks in no small part to some great editing work by Chris and Keith! ;) If you've already seen my talk in person there probably isn't a whole lot new to hear on the podcast, but if not I encourage you to check it out! I think there is definitely some useful info there in regards to where to get started on solving your next big customer problem.

Thanks again guys for having me on and keep up the good work of spreading tech knowledge to all your loyal listeners!

OS X: Essential Software for Developers

noreply@blogger.com (Scott Walker) — Mon, 04 Jan 2010 17:56:00 +0000

Favorite Mac Software

TextMate - The indispensable, extensible, text editor for all your programming and text editing needs.

MacPorts - Package / application management system. Easiest way to install thousands of apps and required dependencies without having to pull source recompile, yada, yada...

QuickSilver - Can't live without this if you are a keyboard junkie.

CleanMyMac - OK... I admit it... I'm *totally* OCD when it comes to PC cleanliness. The fact that I know that uninstalling apps doesn't get rid of all their related junk drives me nuts. CleanMyMac will fix that problem as well as many other routine maintenance tasks.

Evernote - You take notes right? Keep em in the cloud and synced across all your devices. With plugins for all major browsers, there is no better note client than this.

MacLoc - I like to be able to lock my machine without logging out and closing all my apps. Seems like something that should be built into the OS, but it doesn't appear to be there in OS X. This program solves that problem.

OmniGraffle- If you do any significant form of diagramming this is the tool for you.

p4Merge - This is the merge client I'm currently using and have setup with GIT. I hear Araxis Merge is the bees knees, but it's also not cheap. Really wish BeyondCompare had a mac version. *sigh*

Pixelmator - My photoshop replacement. It's an absolutely gorgeous (and affordable) app for those times when you need to get your hands dirty with some image editing.

SizeUp - One of the features I *love*, *love*, *love*, about Windows 7 was the new shortcut keys for sending windows around the screen. Either to certain positions / sizes, or to other monitors. Also one of the hardest things I've had to get used to on OS X is the non-windows way in which window management is handled. SizeUp solves this issue for me by giving me back the windowing features of Windows 7.

Tweetie - My twitter client of choice. No holy wars here, just the one I like the best.

Growl - Get notifications of events happening on your system in an unobtrusive way.

iStat Menus - Ever want to know what the hardware on your mac is doing? This program will tell you at a glance on the menu bar.

VMWare Fusion - Great virtualization app for running your Windows VMs. One mistake I made was not creating a partition for my windows installation thereby allowing me to boot into it natively using bootcamp, or as the VM from inside OS X. One of these days I'll correct that.

Visor - Gives you a globally available terminal window available from a hotkey. This one is the hotness for developers who find themselves using the terminal a lot.

AutoTest + Growl - Not really an application per say, but I love the autotest/zentest tool as a way to help guide my TDD. This will automagically monitor a folder containing some ruby specs and run the corresponding specs every time you save either the spec, or the source file. Set it up with growl and you will be notified by growl about whether your specs passed / failed. Also recommend setting up the fsevent library to reduce CPU overhead and save yourself some battery life.

Software Engineering Conference 101

noreply@blogger.com (Scott Walker) — Thu, 24 Sep 2009 02:25:00 +0000

Today I was honored to be a presenter at the Software Engineering 101 Conference organized by Jim Holmes in Columbus OH. This was a great little conference idea put together and organized by Jim as a way to get back to some of the basics people need to know about developing good software. There were sessions on things such as OOP, SOLID, TDD, and of course my talk on debugging.

The great thing that set this conference apart for me from many others I've attended in recent memory was that there was a very high degree of new faces in attendance. I attend a fair amount of events and so have come to at least be familiar with a lot of people in this region so I was surprised by this. The same sentiment was echoed by my fellow speakers who all agreed with me that this is a great thing! These are exactly the people we want to be reaching out to as speakers and helping to learn new and cool things that they can then take back and share with their coworkers and peers.

I can't claim to know everyone's thoughts on the subject, but for me that is the reward I feel from giving back to the community through speaking... The sense that maybe I served as the spark that started a fire that will continue to grow and spread carrying good engineering practices with it. The more we all pitch in to educate each other, the better all of our lives are going to be.

Slides for the talk can be found here. These are the Devlink specific version, but 99% of the content was the same I talked about today.

Dayton .NET UG Presentation Followup

noreply@blogger.com (Scott Walker) — Thu, 27 Aug 2009 13:48:00 +0000

Big thanks to Joe Wirtley, Jim Holmes, and Justin Kohnen for hosting my talk on Production Debugging last night at the Dayton .NET User Group. Thanks also for all the attendees that came out to learn something new! The feedback was tremendously positive, which makes the experience for me as the speaker very rewarding.

During the presentation Joe suggested that I post some links here about how to setup Symbol/Source server, which I think is a fantastic idea. So the best links I've come across to get all this stuff working can be found here:

Setting up a Symbol Server
Setting up Source Server

In addition for more great reference material on symbols, debugging, windbg, etc... please see my del.icio.us bookmarks here. I have many items tagged with "debugging", "windbg", "symbols" and other terms I talked about last night that represent the best links I've found from across the web over the years I've been doing this.

For presentation content please see the link in my post about my presentation at Devlink, as the content is 99% the same.

Devlink Conference

noreply@blogger.com (Scott Walker) — Sun, 16 Aug 2009 02:59:00 +0000

Got back a few hours ago from the Devlink conference in Nashville TN. Kudos to Jon Kellar and all the other folks that worked extremely hard to put together a great conference. Thanks again to those same people for giving me the opportunity to speak to other passionate developers at such a great venue. My experiences at this conference opened my mind in some ways I wasn't expecting (which I'll blog about later once I find the right words to say what I want to say).

As a followup to my presentation I wanted to add the answers to the two questions that were asked that I didn't have good answers for at the time.

1) What permissions are required to use ADPLUS.vbs to get memory dumps?

Extensive searching on google for the answer to this question turned up no results. I know that for visual studio remote debugging however things tend to work much more easily with admin privileges. I imagine the same would be true for ADPLUS. If anyone does happen to find a definitive answer to this question please post it in the comments for all to share!

2) Do these techniques work for the .NET Compact Framework?

From the research I did I could not find reference of anyone using WinDbg to debug memory dumps of .NET CF applications. I did however find this blog post describing how one could go about finding memory leaks in a .NET CF application that I thought might be useful.

Thanks to everyone who gave feedback on my presentation! I had a great time doing it and I hope that everyone in attendance was able to learn something useful from it. You all are the reason I keep doing this so I can't say thanks enough for all the kind feedback I've received.

The slides / example scripts can be found here. (Note that the virtual machine is too big to host anywhere, but you can always download the BuggyBits application source from Tess's website.)

A Programming Renaissance Affair

noreply@blogger.com (Scott Walker) — Sat, 25 Jul 2009 19:15:00 +0000

So I've been experimenting a lot recently with Ruby during my free time. Writing some simple applications and exploratory tests to help learn the many interesting nuances of the language. The feeling that has consistently struck me throughout this period is one of profound... freedom. At first I thought that this feeling was merely a reflection of the expressiveness of the syntax, the abundance of helpful libraries available, or the way things just seem to work. I still think those things are a part of that feeling, and I'll dive into those with more detail later. After significant further reflection though, I'm starting to believe that there is a much deeper reason for those feelings as well...

In my daily work I primarily write .NET code using all the fancy visual tooling of Visual Studio and R#. The work I've done in Ruby thus far has been something of a programming Renaissance for me. For the Ruby work, I've been working with primitive tools (SCITE, command line, etc...), and as a dynamic interpreted language, Ruby necessarily lacks a lot of the static type trappings and compile time warnings of languages like C# or Java. This has been quite a change for someone like me whom has said on numerous occasions that I don't know how I would live without R#. It's been a very different experience programming with almost no fancy visual tooling. Most strange indeed because I haven't missed any of it one bit! I've heard similar phenomenon described by other rubyists, but never understood or believed it until now.

Which brings me back to the main point I'm getting to. I've been reading Uncle Bob Martin's clean code tips of the week recently which have had me ruminating quite a bit on the various topics of code quality. It was Clean Code Tip of the Week #9 however that really got me thinking. In this tip the intrepid adventurers are recounting tails of a time in the past when it took 24 hours to run a program on punch cards. Because of this they spent inordinate amounts of time manually reviewing their code to make sure things worked right, and consequently they had very few defects. We live in a golden age compared to that were compute resources are cheap enough and fast enough we can let the computers do a lot of that heavy work for us. This all seems great on the surface, but I'm beginning to wonder if all these advancements in technology don't have a much darker un-talked about downside.

One thing I have definitely experienced during my renaissance affair with Ruby, is that I've felt myself thinking much more carefully about the code I was creating. Without static typing to warn me at compile time about type mismatches, and things like intellisense to easily discover parameter and method return types it becomes much more important to pay attention to the details of variable naming, parameter counts, object orientation, etc...

All of this begs the question in my mind of: have advancements in technology, and visual tooling actually been making us dumber or lazier by allowing us not to exercise our brain? Biologically / psychologically speaking, as I understand it, our higher-order brain functionality is one of th key characteristics of what makes us humans. If we offload too much of that processing to machines, what is left to define us as humans? Not directly related to programming, but I certainly know I'm not alone in thinking about these issues. Some time ago Rick Strahl blogged about how he felt as though the rise of search technology has been diminishing his mental capacity. His blog post (which I can't seem to find at the momemnt) very closely echoed my own thoughts on the matter. If we can search anything at a moment's notice why do we need to remember it? Are we stifling our own creativity and innovative capacity by having any answer we desire readily available at our fingertips? Are we as programmers (and indeed society in general) doomed to head down a Wall-E esque path of increased technological oversight leading to humanity's complete inability to do anything for ourselves without assistance?

Perhaps more importantly, or at least more approachabble is the question of are these tools really needed? The claim of course is that they are productivity boosters, but is that really the case? Having witnessed some true Ruby experts at work it was nothing short of amazing what they could accomplish in an hour with nothing more than VIM. As another example, I used to work on software written in an obscure language called DIBOL on VAX/ALPHA systems. There was no such thing as a GUI on these systems so your only option was to use a good text editor such as TPU. When I first started that job, coming from a windows background I railed at the lack of intellisense, etc... and sought ought and found a windows based text editor that would at least give me syntax highlighting for this obscure language. I convinced the company to buy me a copy and spent several painful weeks working with it. It was a ridiculously painful process because I would edit the source on windows and then have to FTP it to the VAX to compile and run it. After witnessing my boss crank out some code like nobodys business with TPU I finally broke down and decided to learn the tool. Within a few weeks I whipping out DIBOL code like I'd never done before and my productivity only continued to increase as my familiarty with TPU became greater. I know that Jimmy Bogard recently had a similar experience at the NFJS conference where he witnessed Stuart Halloway a Clojure master complete an absolutely insane amount of work in an hour using Clojure. I certainly think that there is some evidence at least to suggest that these so-called productivity boosting tools are just a band-aid for deficiencies in some of our common programming languages.

Don't get me wrong, there are some *great* things about R#, VS, etc... and certainly people can use these tools effecively without writing crappy code. I do wonder however it wouldn't be better to make these tools something that people have to earn over time through demonstration of mastery without. If we give new programmers in college all these tools right from the get go, and they become dependent on them to help them write clean code, will they still be able to stand on their own when the crutch has been removed? Will allowing tools to point out all the smells in their code for them cause them to be blind to the smells they create when the tools are not present?

An exercise for the reader is to create a reasonably complex system using your statically typed language of choice and your favorite visual tooling. Then create a reasonably complex system using Ruby and a basic text editor. Come back to both after a few months and see which is easier to reabsorb. Another exercise is to spend some time watching someone who is a true expert with an alternative language at work for a while without all the fancy tools we have in .NET. I think the results might be eye opening.

All that being said, I am totally loving the Ruby language and all the tools that have sprung up around it. As I said to someone else recently, once you pierce the veil of static typing as being some kind of safety blanket you can stop worrying about angle brackets and interfaces and just get down to business. Ruby is just that... a language designed to get out of your way and help you get things done. Rarely have I found what amounts to reading a reference novel for a language an enjoyable experience, but the Pickaxe has truly been a fun read. Also some of the frameworks built-up around Ruby are completely amazing in their simplicity and power. Things like Sinatra, Heroku, etc... make it incredibly easy to get a site up in running (the way YOU want it) in no time flat.

Along with Ruby has come my first exposure to GIT which at least from my limited experience thus far seems like "source control done right". I've got a lot more reading to do on the topic, but so far I think TFS and heavy-handed SCMs are for the birds.

I Fought the AJAX and the AJAX Won!

noreply@blogger.com (Scott Walker) — Tue, 21 Apr 2009 02:13:00 +0000

So up until a few days ago I thought I had a pretty good handle on how all this AJAX stuff worked. It was at that point investigating what seemed to be a pretty innocuous bug report that I we ran into a particularly painful behavior of the XMLHTTP object that made me rethink my assumption. The behavior makes sense once you give it some thought, but is not at all obvious at first which is why I'm posting the story here both so I can remember it and so hopefully someone else will benefit from the information.

So picture for a minute a scenario where you have an input form that a user must fill out before clicking a button to submit the form. Some of these input fields are textboxes that require some complicated validation logic (easy to do on the server, but difficult on the client) that you run to ensure that the entered data is valid. To get the best user experience you want to have the validation appear to be on the client side, occurring right after the user leaves the field. To achieve such functionality you may have likely taken the same approach that we did of attaching an onchange event handler to the input element that makes an AJAX request to the server to perform the validation. And this is where the problem begins...

Likely (as we did) you want the input to be validated and any errors flagged for the user before you submit the whole form to the server. Therefore it makes perfectly logical sense to execute the AJAX request synchronously so that it blocks further downstream processing from occurring until the validation routine has had a chance to finish. So you test all this functionality and it seems to be working just great and life is good... or is it...?

So the next functionality you add is the ability for the user to submit the form which requires some javascript processing of its own. So you wire up an onclick event handler to the submit button and you think you're good to go... until...

A user testing the application finds that if they change the value in one of the input fields that is using the AJAX validation (to an invalid value) and then immediately click the select button before clicking elsewhere on the page that the validation does not prevent them from submitting the form. A simple example could be as follows:



<html xmlns="http://www.w3.org/1999/xhtml">
<head>
 <title>Untitled Page</title>
 <script language=javascript type="text/javascript" src="Scripts/jquery-1.3.2-vsdoc.js"></script>
 <script language="javascript" type="text/javascript">
  $(document).ready(function()
  {
   $("#mybutton").click(HandleClick);
  });
 
  var lastTextBoxValue = "";

  function HandleClick()
  {
   console.log("HandleClick:"+lastTextBoxValue);
  }

  function HandleChange(input)
  {
   console.log("HandleChange Before Ajax");
   $.ajax({ url: "EventTest.html" });
   console.log("HandleChange After Ajax");
   lastTextBoxValue = input.value;
  }
 </script>
</head>
<body>
 <div id="mybutton" style="border: 1px solid black; background-color: Aqua">
  Click</div>
 <input type="text" onchange="HandleChange(this)" />
</body>
</html>

EGADS! What possibly could have gone wrong with such simple functionality??? Firing up the debugger you swiftly realize that something very strange is going on... Setting breakpoints anywhere in the chain of processing appears to prevent the issue from happening. So you spend several hours banging your head against the wall looking for an answer.

That is, of course, unless you happen to have read this blog post and have learned from our frustration in finding the cause of this issue. To make a long story short what is happening here is that using the XMLHTTP object in synchronous form does not behave exactly as you might expect it to at first blush...

A synchronous request does in fact block further execution of javascript in the current execution stack that led to the request as one would expect. What it does *not* block however is other execution stacks that may have been triggered by other asynchronous processes such as events like a button click! So in the validation case where you changed an input value and clicked the submit button what you would see is:

onchange event of the input field fires
synchronous AJAX request begins
click event of button fires

The behavior makes sense once you realize that if the synchronous call blocked all javascript from processing that it would basically lock your browser and prevent such scenarios as having a cancel button to cancel a long-running synchronous request.

We haven't found a great solution to this issue yet, but I'm throwing this out there as a word of caution to all that there is a reason the abbreviation stands for ASYNCHRONOUS Javascript and XML. I've seen time and time again that if you fight the asynchronous nature too much you usually end up burning yourself sooner or later.

In addition, please see Jeff's comments below for why this behavior might be a little more nefarious outside of my validation example. He actually did a lot of the work on finding this bug, but since he hasn't got his blog up and running yet I'm posting it here.

Some further reading materials on javascript timers / events / performance that can help to understand all this better are:

CINNUG Presentation Followup

noreply@blogger.com (Scott Walker) — Wed, 25 Feb 2009 15:52:00 +0000

Last night was my second go-round giving my Production Debugging talk. This time it was for the Cincinnati .NET User Group. This group is run by a great group of people, Mike Wood, Matt Brewer, & Phil Japikse (sorry if I left anyone out). There was quite a turn-out last night at 67 people, nearly setting the record for the group! I was impressed by the passion and insightful questions of all those in attendance and want to give thanks to the organizers as well as the attendees.

Feedback thus far has been extremely positive which goes a long way to validate why I believe so strongly in the .NET community and getting involved in giving back. Hopefully everyone there last night learned a few new tricks and will be better prepared for when those critical issues happen.

One question came up last night that threw me for a bit of a loop and so after ruminating on that question some more last night I wanted to go ahead and address it here on the blog. The question was roughly:

During the crash demo why didn't you open the 1st Chance NullReferenceException dump? Wouldn't that have shown us the original error and location without having to jump through hoops in the 2nd chance dump to find it?

This was a great question, and in reference to this particular simple crash demo was spot on correct! For this very simple case opening the 1st chance dump would have been a quicker way to get to the root of the problem. For more complicated crash scenarios however this likely would not have been a good choice. If we remember what I spoke about last night in regards to how exceptions are handled, the 1st chance exceptions occur when the exception is first thrown and the application has not yet had a chance to handle that exception. Therefore in a more complicated scenario there potentially could have been multiple 1st chance exceptions of NullReference or other types out there that had corresponding dump files written but were actually handled gracefully by the application and not the source of the actual application crash. In those types of scenarios we want to make sure to open the 2nd chance dump so that we can be sure that we are looking at the actual UNHANDLED exceptions.

As promised, I have attached all the presentation materials to this post so people can refer back to them later. There are a lot of files in the package, so I recommend first checking out the Readme.docx which talks about what each of those files represents.

Please feel free to leave any comments / questions you may have either here on my blog or ping me on twitter.

Happy debugging!

Farewells Are Always Hard

noreply@blogger.com (Scott Walker) — Sat, 07 Feb 2009 04:20:00 +0000

I’ll stand by the statement I made several months ago to my buddy (and now co-worker) Jeff that I think we’ve got a pretty stellar team at our current place of employment. Unfortunately today that team got a little weaker with the departure of another friend and co-worker, Lee. It seems to be be a bit of a disturbing trend these days that a lot of good people I know are either leaving or being forced to leave their current places of employment. Perhaps that is just the way things have been and will always be in troubling economic times, but I’d certainly like to hope for better.

It’s always hard to say goodbye to a good co-worker, and even harder if they happen to be a friend as well. After working at a few different places in this business I think you come to realize that one of the most important factors in being happy with your job is getting to work with really smart, passionate people who share your same interests. Those people seem to be few and far between these days, especially as companies attempt to outsource and contract resources from other sources. This makes it all the more important to do everything you can to hold on to those good people when you’ve got them. It’s unfortunate that sometimes companies don’t realize the value of keeping that well-oiled machine of a good team whole.

I’s hard not to feel at least a little pang of guilt as a part of management when you do lose one of those. You always wonder if there was a little something more you could have done to change their minds, or better yet, to stem the underlying tide of discontent before they began considering other options. I can honestly say that the team I work with is one of the most important factors I weigh when evaluating my career opportunities. I want to be a part of a really good team, and more importantly I want to be a part of making that good team into a *great* team.

With that in mind I plan on spending more time being a little retrospective in the coming months. Focusing some time on energy on what I can do to become a better manager to those I work with. It’s easy for me to get lost in the technology sometimes because it’s what I know. It’s safe and comfortable and easy to learn. Management on the other hand is a relatively new thing for me, and I believe something infinitely harder to learn to be great at than simply banging out code.

Lee… Goodbye and good luck with your new endeavors. You’ll be missed.

ASP.NET Ajax Ate My Site

noreply@blogger.com (Scott Walker) — Tue, 09 Dec 2008 01:59:00 +0000

So despite all the doom & gloom people have posted in the past about using ASP.NET AJAX’s UpdatePanel control we’ve gone ahead and used it in one of our applications. Things were going along quite swimmingly for a while until one day with a particular customer’s data we encountered a severe performance problem any time an async postback occurred. The odd thing was that the bug was only reproducible in IE7/8.

The screen would pretty much freeze up and after a while we’d get that wonderful dialog box stating that scripts were taking to long would you like to let it finish or stop it? Firing up the nice JavaScript profiler in IE8 revealed that ~18 seconds of time was being spent in the destroyTree function from the ASP.NET Ajax JavaScript library. hmm… interesting…

Poking around a bit more revealed that this function is called whenever an UpdatePanel control has new content being loaded from an async postback. It’s purpose is to loop through all of the DOM elements inside the UpdatePanel and ensure that any javascript objects / behaviors attached to the elements get their dispose method called. This seemed like a rather trivial task to be taking that amount of time. Poking around a bit more revealed that in the particular UpdatePanel that was being destroyed we had ~7000 DOM elements. Having that many DOM elements in and of itself is a separate problem that we need to address, but still didn’t explain why any browser but IE could handle this task in ~1 second compared to IE’s ~18 seconds. Apparently walking a large DOM tree in IE is *appallingly* slow!

After a bit of google searching I found that this issue has been discussed at least a few times on the ASP.NET Ajax community forums. Most people seemed to suggest to write some code to manually clear out the DOM elements of the known problematic DOM nodes before the framework has a chance to call destroyTree. Hating to hardcode special cases for specific elements I set out to create a generic fix and came up with the following:


function DisposeItems(sender, args)
{
$.each(args.get_panelsUpdating(), function(i, panel)
{
  destroyTree(panel);
});
}

function destroyTree(elem)
{
$("[dispose],[__behaviors],[control]", elem)
  .each(function()
  {
    if(this.dispose && typeof (this.dispose) === "function")
      this.dispose();
    else if(this.control && typeof (this.control.dispose) === "function")
      this.control.dispose();

     $.each(Sys.UI.Behavior.getBehaviors(this), function(i, behavior) {
        behavior.dispose(); });
     });
elem.innerHTML = "";
}

Sys.WebForms.PageRequestManager.getInstance().add_pageLoading(disposeItems);

Hooking into the framework’s pageLoading event that is called when new async postback content is received we use a little jQuery magic to basically take over the work the framework was doing to ensure that all the dispose methods are called properly. For each of the UpdatePanels that are going to be updated with new content we call our own implementation of destroyTree. Our implementation instead of looping over all ~7000 nodes uses a jQuery selector to find all the elements that need disposing. Then we simply duplicate the framework’s dispose functionality. Finally we clear the innerHTML of each element effectively removing the nodes from the DOM. This way when the framework’s destroyTree function is called it has practically no work to do.

From a performance standpoint, this fix reduced the time we were spending in IE to destroy the tree from the previously ludicrous ~18 seconds to around ~1 second which then put IE on par with the other browsers. This was an interesting one to find and fix and I hope Microsoft finds a better way to solve this in the next version of the framework so we don’t have to continue to hack around it. Who knows, now that they have officially embraced jQuery maybe they can reuse my fix!

Citizens of Wisconsin UNITE!

noreply@blogger.com (Scott Walker) — Tue, 25 Nov 2008 22:52:00 +0000

This is a letter to the hip-hop artists of America. I've stood silently by all these years without saying much about the content of your "music" as quite honestly some of it is very catchy if not entirely satisfying. I've stood silently by all this time despite the questionable moral content of your songs that glorifies boozing, whoring, and drug consumption. I've stood silently by all these years despite your inability to have even a rudimentary command of the English language, creating words such as "shorty", "drizzy", "crunk", "drank", etc...

Your most recent flagrant abuse of the Enligsh language however has finally pushed me over the edge. You see, the other day while listening to the radio I heard a song (whose name escapes me at the moment) that for lack of a better word attempted to rhyme "Wiscansin" with something. I'm not afraid to say that I threw up a little bit in my mouth upon hearing this. "Wiscansin"??? Seriously!?!?! That's the best you can do? Making up words wasn't cutting it any more so you had to bastardize the name of a state? You've given up even trying to be creative and have now resorted to Dr. Seuss like nonsensical words?

If I were a citizen of the great state of Wisconsin right now I think I would officially boycott from this moment on all forms of hip-hop, ban it's playtime from radio stations, and force relocate all hip-hop artists living in the state to the land of Whoville where they so clearly belong.

To those of you out there who actually like this kind of drivel I pity you for every minute you spend making yourself dumber by subjecting yourself to such folly.

On Quality

noreply@blogger.com (Scott Walker) — Thu, 06 Nov 2008 20:21:00 +0000

At our book club meeting today on Evan's Domain Driven Design we got into a rather passionate discussion of whether quality is something you can negotiate. There were good arguments presented on both sides, but I'm firmly in the camp that quality is never something that should be on the negotiating table.

I'm fine with saying that under specific circumstances (one-off, non-asset projects) you can save time by sacrificing on certain design patterns or principles that don't make sense. For instance using LINQ To SQL instead of NHibernate, or ADO.NET vs full blown repositories, etc... Those things to me are all design principles and patterns that promote flexibility not quality. What you can't sacrifice on are the basic principles of SOLID:

SRP: Single Responsibility Principle

THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE.

OCP: Open Closed Principle

SOFTWARE ENTITIES (CLASSES, MODULES, FUNCTIONS, ETC.) SHOULD BE OPEN FOR EXTENSION BUT CLOSED FOR MODIFICATION.

LSP: Liskov Substitution Principle

FUNCTIONS THAT USE ... REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT.

PTOM: The Liskov Substition Principle by Chad Myers -- My own post on the subject

ISP: Interface Segregation Principle

CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE

PTOM: The Interface Segregation Principle by Ray Houston

DIP: Dependency Inversion Principle

A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS

B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS

PTOM: The Dependency Inversion Principle by Jimmy Bogard

These things like paying attention to cohesion and coupling are the fundamentals of good software engineering that allow any program no matter the design methodolgy or patterns used to maintain good quality. You can sacrifice on scope or flexibility, but not on good principles, unit testing, or QA... PERIOD.

Any customer who wants to put quality on the negotiating table is one that you should probably walk away from! As a consumer you wouldn't ask an auto manufacturer to sacrifice on passing the government safety standards would you? Granted most decisions are not of that life or death nature, but whenever you building anything for a customer that thing is of some essential value to the customer and their business process. If it isn't adding essential value, or the customer is saying that they are willing to sacrifice on it's quality they are implicity saying it has lower value so why are you bothering to build it? The customer would most likely be much better served by refocusing the effort that would have gone into half-assing that feature into one that does provide some essential value.

So in the end I think you can't sacrifice quality, and if you stick to that as an unflinching principle the majority of customers will likely respect you for having the gumption to stick to your core values. If not you should probably strongly question if you want them as a customer in the first place.

Screencast Coming Soon

noreply@blogger.com (Scott Walker) — Fri, 02 May 2008 12:56:00 +0000

In my last post I mentioned that I would be posting a screencast version of my CONDG debugging presentation sometime in the future. I am hoping to get that up sometime next week. Unfortunately I have been sick this week with fever and sore throat so I haven't exactly felt like giving a 2 hour long talk. So I apologize for the delay in getting that done, but the good news is that when I do get around to posting it, it will be an extended version with some new content I've thought of since the presentation as well as some other content that we had prepared for the presentation but didn't have time to get into.

So keep your eyes peeled on this space and I promise I'll get it up here soon.

CONDG Debugging Presentation Followup

noreply@blogger.com (Scott Walker) — Fri, 25 Apr 2008 12:58:00 +0000

It was a long haul the last couple of weeks trying to get all the details hammered out for my presentation on Production Debugging for CONDG. Now that the presentation is over and the dust has settled I can emphatically state that all the hard work has been worth it. The feedback so far has been overwhelmingly positive and for me that makes it all worth while. Lots of people in this community have helped me out in various ways over the years and I'm extremely glad that I could give something back.

Were there things that we could have done better? Sure! (I apologize wholeheartedly for the technical foibles) At the end of the night though I think everyone learned some cool new tricks they didn't know before, and that was really what I was hoping for. I'm sure people aren't going to remember all the minute details of everything we talked about, but as I said last night, at least everyone there now has taken the first step towards having a "catastrophe plan" in place.

Briance Prince our resident MS Architect Evangelist has suggested that we do a webcast of the presentation for the world at large. Because of the technical nature of the presentation and the demos we did I think this is a great idea and so we will get this done sometime in the future. I don't want to promise a timeframe yet, but we will be doing this at some point. For the webcast we will likely also do the expanded version of the presentation in which we cover some details on the garbage collector and how you can use WinDBG to find memory leaks in your applications.

In the meantime we will at least be posting a short screencast that shows of Bryan's super-sexy demo that we didn't get to show last night. We'll get that up in the more immediate future. In addition, because things went so well last night we will also likely be trying to pimp this presentation to other conferences around the area throughout the rest of the year. I know I'll definitely be angling for a session at CODEMASH '09 so we can reach a larger audience.

Again, thanks to all who came out last night, and special thanks to my employer TDCI for believing in the community and ponying up the funds to sponsor last night's meeting. For those of you who are waiting on some answers to questions that you had for me after the presentation, I'll be in contact soon with whatever I can find out.

In the meantime please go ahead and grab the slides and check out some of the links in the deck. There are some blogs linked in there that know far more about this topic than I do!

Ultimate Debug Tool List

noreply@blogger.com (Scott Walker) — Fri, 14 Mar 2008 20:15:00 +0000

As a prelude to my talk with t-SQL ninja in April for CONDG about advanced debugging and production debugging I thought I should write a post about the tools that I commonly use in these scenarios.

Windows Debugging Tools -- First and foremost for production debugging scenarios the tools that you should become intimately familiar with are the parts and pieces of this package. It includes a ton of useful debugging tools of which I'm going to only highlight the few that I use most often here. These will likely be the primary focus of my talk in April.
- WinDBG -- This is in my opinion the ultimate windows debugger available. It can debug just about any scenario and is especially useful for post-mortem debugging scenarios. Lots of people way smarter than I have written great articles about using WinDBG to help in solving common debug problems. I owe them and many others thanks for taking the time to blog in such detail and opening my eyes to the possibilities this tool provides. By default WinDBG is a native only debugger but there are a couple of extensions that one can use with WinDBG for debugging managed code.
- ADPLUS -- This is a VBScript that can help to automate a lot of tasks such as gathering memory dump files of a process upon certain exception conditions, application hangs, crashes, etc... It's highly configurable through the use of an XML file so that you can very finely tune how and when you want to generate a memory dump, write log information, or break into a process.
- SYMSTORE -- Microsoft symbol server utility. This allows you to store debug symbols and even binaries for use by debuggers that support symbol servers. Basically what this means is that if done properly, your debugger can automatically download the proper debug symbols and binaries from some server when you are debugging a piece of code. This is especially useful for post-mortem debugging where all you have is a crash-dump. Having debug symbols available will really make your debugging life easier as you will now have call stack information at the very least.
- TFINDEX -- Source server support for Team Foundation Server. This takes the symbol server concept discussed above to a whole new level! The idea is that you run this on your debug symbol files before storing them in your symbol server. Then when you are debugging a piece of code along with pulling the proper debug symbols and binaries from your symbol server your debugger can also talk to your source control server to pull the actual source files for the code you are debugging!
Reflector -- If you are a .NET developer and you've never used Reflector before you should probably reconsider calling yourself a .NET developer. Reflector lets you peek inside assemblies and dissect the source code, embedded resources, etc... Where it becomes very useful in debugging is when you don't happen to have the source for a particular assembly but you do have access to the assembly itself. If you know the method where a failure is occurring from a stack trace in an error message or memory dump you can load the assembly in reflector to peek at the source for the method and get an idea of what might be causing the failure. It used to be the only good way to take a peak inside the .NET framework DLLs if you had an itch to know what was going on in there. There are also a wealth of add-ins available for Reflector to extend its capabilities in various ways.
Fiddler -- An indispensable resource for you web developers out there. It acts as an HTTP debugging proxy between your machine and the net allowing you to inspect network traffic, set breakpoints, and otherwise mess with the data. It also includes a powerful scripting system to enable even more advanced scenarios. I find this tool particularly useful in applications that make heavy use of AJAX. Often times when things go wrong in out-of-band calls only strong knowledge of the HTTP pipeline and a network tracing tool can help you find what's going wrong.
Network Monitor -- This is the big brother to Fiddler when you need to get *really* low level with your network traffic analysis, analyze traffic outside of just your machine, or analyze traffic other than the HTTP variety. Like Fiddler it is highly customizable, scriptable, etc... It has a steep learning curve, but if you really need to get to this level of analysis to solve your problem you're probably already in deep doo-doo.
Process Monitor -- Originally developed as three separate tools (Filemon, Regmon, Procmon) by SysInternals after being bought by microsoft it has been compiled into one tool. This can be used to monitor activity against the registry and file system on your machine, as well as running processes. Useful in a number of situations such as permissions errors.
Performance Counters -- Often times finding a problem is a process of elimination. Often times performance counters can be a good place to start that process. For instance, when troubleshooting memory issues a quick examination of memory related counters can indicate the type of leak that is occurring. A jump in virtual bytes while private bytes remains stagnant points to a component reserving memory but not using it. So understanding what counters are available, what they mean, and how to use them can really narrow down the focus of a bug hunt.
SQLExpress Profiler / SQL Profiler -- If you believe you've got something going wrong with your access to your database these are the tools to use. They provide customizable filtered tracing of all SQL requests going to a server.
Windows Event Log -- Often this is the first place to begin a bug hunt. Many system and application errors get logged here by default. Sometimes these messages will provide you with the exact information you need to solve the problem, while other times it can at least point you in the right direction.
Trace Files -- Hopefully the application you are debugging writes its own log files in the event of an error. If so this would be the first place I'd check when a problem occurs.

Well that's it for now! If anyone knows of other great debugging tools I should check out feel free to leave a comment and I'll add them to this list.

Performance -- The Implicit Feature Request

noreply@blogger.com (Scott Walker) — Sun, 24 Feb 2008 01:09:00 +0000

I've been giving some thought recently to the fact that a lot of companies, and also a lot of developers don't give enough thought to application performance. It's something I know I've been guilty of at times so don't think I'm just pointing fingers. There is a very fine balance to be struck between being performance conscious and falling prey to premature optimization. Like most things, it's a balance I think that can be found by the application of due dilligence. Just like TDD is all the rage these days because it helps to ensure that your code is thoroughly unit tested (among other things), I believe a little automated performance testing could go a long way.

The observation that made me wander down this path is that when you have a really short release cycle coupled with a mountain of requirements, performance testing is absolutely the first thing to go out the window (if it was even being done in the first place). It is also nearly a foregone conclusion that at least some of the items in that mountain of features are going to have a negative performance impact on an exisiting process in the system. Even in a well-architected, highly-modularized system, the more steps you add to an existing process the longer that process is going to take. This is where a fundamental disconnect in the software engineering process occurrs.

Most users of an application fail to grasp the point I just made above. It's a problem that may actually be even a bit more sinister than it sounds at first. It's my conjecture that users expectations are such that at a *minumum* the application should perform at least as well as it used to, no matter how many new features were added to a new release. In fact, I think it's highly likely that users implicitly expect the performance to increase as a whole with each version... To them, the worth of an application is in what features it offers and it is just a given that those features will perform up to the characteristics they have set forth in their heads. They don't think to list "performance" as a requirement of a project or feature, nor I think should they have to.

As software engineers and software engineering managers we are some of the most demanding software users there are! We tend to have a very low tolerance for software that doesn't function correctly, or speedily enough. Therefore, we are also intelligent enough to know that the users of the applications we create should not have to settle for anything less than the standards we set forth ourselves. It becomes our job then to bake performance considerations into our development process. That means, knowing how to perform meaningful performance testing and budgeting enough time in our estimates to allow that testing to happen.

Given the choice between a meaningful business feature and "performance improvements", end users and product owners are never going to choose "performance improvements" as a work item for a given iteration until performance has become so bad that it is already too late. Once you've reached this point you are in very dangerous territory because as the old saying goes, "the squeaky wheel gets the grease". The more that the end users complain about performance issues, the more likely it becomes that you'll have to get into a situation where you need to drop everything just to placate the angry mob banging down your door. At this point, you're lucky if the steps necessary to resolve the performance issues are anything short of a wide-scale rearchitecting of the system which nine times out of ten is not a valid option. When that happens you then run the risk of missing other established project deadlines which also leads to unhappy users. It's a vicious cycle to break free from and one that should be avoided at all costs.

Time to buy NVIDIA stock?

noreply@blogger.com (Scott Walker) — Tue, 12 Feb 2008 14:41:00 +0000

Is there any geek out there who can read this announcement without practically wetting their pants with excitement? Could it be that my long-standing dreams of the perfect all in one device are nearing reality? If I could get my hands one a device with one of these, a true GPS, and a 32gb MicroSD card I think my life would be complete. Granted it's still going to probably be somewhat crippled by running Windows Mobile, but maybe this explains (aside from pressure from the iPhone) why MS has said that the next version of Windows Mobile is going to be a complete redesign?

Specifications, LINQ, and Lambdas

noreply@blogger.com (Scott Walker) — Wed, 06 Feb 2008 01:36:00 +0000

In our current application that we work on the most our "business objects" follow more of an ActiveRecord kind of model. Well more specifically they are sort of a heavily bastardized version of Rocky Lhotka's CSLA, but who's keeping track? Looking towards the future, I've done lots of research into alternative models that will hopefully help us solve many of the problems we've got with our current implementation. It seems all the buzz these days is around DDD, ORM, IOC, DI, et al. I have to say the more I've read about those topics in particular the more enamoured I've become with them and the very POCO, PI objects they facilitate. Furthermore I like that these tend to favor the use of patterns over specific frameworks.

I was a big fan of CSLA when the .NET v1.1 version of it came out, and used it to some great success on a project back then. I've been following its progress since then and although it certainly has some cool concepts in it, I feel as though it is slowly but steadily succumbing to the problem that is the eventual death of all frameworks, the "silver bullet syndrome". CSLA has increasingly been trying to become everything to everybody and in the process I think it is becoming overly complex and heavy-handed as all frameworks that are around long enough seem to do. He's got some great concepts that I will consider borrowing for our implementations, but the framework as a whole no longer matches my style, nor indeed it seems the community at large.

So back to the original point of this post, as we evolve to a more DDD oriented model than a CSLA oriented one, one of the main challenges we are working on is what the right way to do validation is. I agree with Oren and Udi that there are different types of validation and that they should be addressed in different ways. The first piece of the puzzle I attempted to tackle is what they termed "business rule validation". To me it makes sense that any kind of complex (non-input) validation should be performed by a specific object dedicated to that task as it promotes the greatest flexibility and reuse. This got me to thinking about the specification pattern as this type of validation is just one of the cases that pattern can be used for. The other great use of this pattern is for selecting a subset of objects from a master list, which ties in very well with the repository pattern for object retrieval. This line of thinking eventually lead me to the idea of somehow creating an implementation of the specification pattern that could be used for both validation and entity selection (using LINQ) types of scenarios. It seemed like a reasonable goal and one that could be very beneficial if done correctly.

As I am a #pragma-tech programmer (pragmatic, get it?), I always like to see what work others may have done in the area. I hate being a plumber so I fired up a google search and turned up several articles on implementations of the specification pattern in .NET but the ones that were most interesting to me were this one and this one, both by Ian Cooper. I'll spare you the gory details of how its all works, you can go read Ian's articles for that. In short though, in these articles Ian pretty much lays out an implementation for exactly what I wanted to accomplish, but unfortunately neglected to include a download for the code. Luckily his articles themselves were detailed enough and contained enough code that I was able to get the gist.

As I wanted to spend some time honing my C# / LINQ / lambda skills anyways I decided to take a crack at fleshing out an implementation of what he talks about to see how it all comes together. A few hours later I had it all banged out and the default implementation of what he was talking about worked quite nicely. There were a few warts with it that I didn't much like however that I decided to fix in my implementation...

The first was that the only way to chain specifications was by writing code like this:

Specification ProductSpec = new Specification(p=> p.PartNumber != string.Empty).And(new Specification(p=> p.MinOrderQty > 0));

I didn't like the fact that you had to create a new specification object inside the chaining method to make this work, so I overloaded those functions to also just directly take a lambda expression so you now you can do this which is more fluent in my opinion...

Specification ProductSpec = new Specification(p=> p.PartNumber != string.Empty).And(p=> p.MinOrderQty > 0);

I also added extension methods for the IQueryable and IEnumerable methods that accept an instance of an ISpecification to use as the query filter. I think this is *much* nicer than the way Ian demonstrates doing it in his article as it can be done all in one line instead of the three that it took with his implementation. So now you can do:

var prd =
(from p in products
select p).WhereSpecification(ProductSpecifications.ProductIsConfigurable);

I also added caching of the compiled expression to improve performance.

The end result is a way of creating a single object using a pretty fluent interface that you can then use to validate an object's state, or use in a LINQ expression against any type of LINQ datasource to specify a filter criteria. Pretty cool!

The bits are here...

Special Thanks

noreply@blogger.com (Scott Walker) — Tue, 05 Feb 2008 00:47:00 +0000

I want to give a special shout out today to Josh Holmes and Jeff Blankenburg. I had the opportunity (much to my good fortune) to have a chat over lunch one day while attending Codemash 2.0. We talked about some of the challenges that we are facing at my company when it comes to the design of the user experience for our applications. I attended Josh's ArcReady presentation on Architecting for the UX last year and found it to be an excellent presentation. During our chat at Codemash, Josh offered to re-present that presentation especially for my organization.

Today after coming to town for the ArcReady SOA presentation for this quarter, Josh and Jeff delivered on that offer by coming to TDCI and spending a couple of hours talking to us and answering our questions. I think these guys went above and beyond the call of duty in attempting to tailor the presentation to address some of the specific challenges we face as a company. For that, guys I salute you!

I highly recommend anyone who has a problem in their development process to call upon these guys and see what they can do for you. I guarantee that if they don't have the particular skillset needed to address your issue they certainly know someone who does and will be more than willing to put you in contact with them.

So again, one last time... Josh, Jeff... thanks!

Is Great really great?

noreply@blogger.com (Scott Walker) — Thu, 31 Jan 2008 14:44:00 +0000

Jeff Attwood never ceases to amaze me with his always insightful commentary on oh... just about anything! I truly don't know when he finds the time to put together these incredibly articulate, thought provoking, and well researched blog posts. I am however truly glad that he does as he gives me something to think about on practically a daily basis.

Today's topic from Jeff is about how greatness is achieved. It challenges the old proverb of

"Reach for the stars and at worst you'll land on the roof..."

The premise is that greatness is something that is extremely hard to achieve. It takes an incredibly large set of variables to all have the right values at the right time to be great. The natural variability there makes it nearly impossible to be consistently great. So the argument that I tend to agree with is that the way you achieve greatness is being demonstrably, repeatably, consistently *good* over a long period of time.

I agree with this because I think this applies very much to the way I feel about my own career thus far. I certainly do not consider myself to be one of the "astronaut" programmers out there. I don't live, breathe, and dream code like some of these guys do. I just have too many other interests to let coding be such an all-consuming factor in my life. I do think however that over the course of my career thus far I have demonstrated time and time again that I am very good at whatever it is I choose to do.

So I guess if you believe in Jeff (and the material he references) then that means there is hope out there for all of us who don't consider ourselves to be "astronauts" to one day achieve greatness.

What Movie Plot Is Your Product Support Experience Like?

noreply@blogger.com (Scott Walker) — Tue, 22 Jan 2008 15:10:00 +0000

Every job I've had in my career thus far has been for smaller sized companies. When you work for a smaller company as I have you quickly discover that everyone generally "wears a lot of hats". Everyone is expected to take on responsibilities outside the scope of what it is you were initially hired / educated to do. Being a software engineer by trade, one of the extra hats I've found I had to wear at every job so far is that of 3rd level product support. It's a role that I find engenders a lot of passion in people who have to work it. It's either love or hate with very little in between.

Personally I lean toward the love it end of the spectrum in an odd masochistic sort of way. You see, what I have found is that this role provides some very unique and challenging scenarios, rife with unusual problems that require an out of the box thinker to solve efficiently and effectively. It forces my brain to think in ways that are different from the pattern it falls into during my day-to-day work. Since I had to tackle this role (to some degree) in my first job out of college, the other observation I have made is this:

Ironically, as a software engineer just starting your career, you are likely to make the most mistakes you will ever make, and also least well equipped to find and fix those mistakes when it matters.

It is for that very reason that I have made it my personal "quest" of sorts to find tools and techniques to deal with these types of challenging situations while attempting to maintain my sanity and also have some fun along the way. At some point in the future I will be delivering a core dump of my knowledge accumulated on this subject for the Central Ohio .NET Developer Group.

In the meantime, the mention of a "quest" has brought us, dear reader, in my rambling, circuitous fashion to the point of this post. I was ruminating the other night over some support experiences I've had from a consumer experience with other companies and it occurred to me that with a little thought they could all be likened to movie plots.

The company that I have by far had the most of these support experiences with is Microsoft. Quite often I have found when attempting to find the solution to one complex problem or another that the underlying issue appeared to be coming from one Microsoft product or another. The collective experiences I've had on these calls has lead me to believe that Microsoft has modeled their developer support call process after the plot of the movie The Princess Bride.

As is the case with any movie we must first establish a cast of characters for the plot to unfold around. For the sake of this dramatization, I of course will be playing the part of the strapping young hero Westley:

Westley was just a poor overworked programmer slaving day in and day out to make ends meet. He had big dreams however of one day making lots of money by releasing the 1.0 version of the most beautiful application in the world that he had codenamed "ButterCup".

There was however, just one small problem regarding Westley's dream of living happily ever after with Buttercup... You see in beta testing Buttercup's users discovered a particularly nasty flaw in buttercup. A particular sequence of events that seemed to occur on a monthly basis would cause Buttercup to fly completely off the handle, corrupt important data and give the users one of these:

This was obviously a serious roadblock in Westley's plans as a an error this serious in nature was unacceptable in production level software and therefore was preventing him from releasing the product. Not to be deterred, Westley did the only thing he knew to do and fired up his trusty development environment and attempted to debug the problem. As it turned out, this was a particularly precocious problem. Westley put forth a herculean effort (akin to climbing the cliffs of insanity) attempting to find the source of he issue. Many sleepless nights and many cases of bawls later he was exhausted and no closer to solving the issue. The one good thing that came out of all this work was that problem did not seem to be occurring as a result of Buttercup's application code, but rather a bug in a Microsoft component used by the application.

It was at this point that with no other place to turn Westley decided to place a call to Microsoft developer support. The person that picks up the line on the other end is none other than this guy, let's call him Inigo:

Inigo sensing the frustration and exhaustion in Westley's voice very respectfully proceeds to ask Westley a series of questions:

Who are you?
Do you have a support case number?
What are you calling about?

And quite suspiciously...

Do you by any chance have six fingers on your right hand?

Westley, quite baffled by the last question and sensing Inigo's growing impatience over the duration of the conversation deftly steers the conversation in a new direction and so the duel begins... It's a fierce exchange to behold! Inigo presses Westley hard suggesting incorrect product groups he should be directed to next. Westley in turn parries with an alternate suggestion, and Inigo counters with yet another. The battle rages on for some minutes until Inigo finally succumbs to Westley's masterful negotiation skills, and transfers Westley on to become someone else's problem to deal with...

And now a new person is on the other end of the phone line... Let's call him Fezzik:

Fezzik and Westley converse for a few minutes in which Westley has to re-answer most of the questions he prviously answered for Inigo. It quickly becomes apparent to Westley that Fezzik is not the brightest bulb on the strand and will be no help to him on his quest to save his beloved Buttercup. In fact it appears that Fezzik's sole job on this call is to bludgeon Westley to death through brute force, repetitive, inconsequential questioning! After an excruciatingly painful exchange, Westley through sheer perseverance and determination finally manages to overcome the fearsome giant with the mind of a mental midget. And again he is transfered on to become someone else's problem...

At this point, INCONCEIVABLY, a new voice comes on the line... The voice belongs to a weaselly little man we shall call Vizzini:

Vizzini is a crafty little fellow with an over inflated sense of his own self-worth. He boasts of how much of a genius he is saying things such as:

"Let me put it this way: have you ever heard of Guthrie, Hanselman, Ford? ... Morons!"

It is clear however that Vizzini holds Buttercup hostage by not providing the answers Westley needs and thus Westley must somehow find a way to overcome Vizzini. Vizzini attempts to get the best of Westley by using flattery and misdirection and generally flaunting his self-perceived massive intellect. He offers suggestions and hints that seem likely to work just to throw Westley off the track as he can not ever admit to being wrong. In the end however it is Westley who triumphs. With the facts and evidence on his side Westley turns the tables on Vizzini by providing two samples that clearly demonstrate the issue (poisoning both goblets if you will) that clearly demonstrate the problem. In the end Vizzini concedes, admits to being wrong and provides Westley a hotfix to test that should solve all of Buttercup's problems.

So now Westley with Buttercup in tow must navigate the technical and political quagmire of updating the beta clients environments and re-testing the application after the fix is applied. There are many perils to this particular quaqmire...

Creating a proper hotfix package for the application.
Ensuring correct application of the hotfix to all beta customer environments.

Both of which are easy to avoid once you know what you are looking for. The real danger in all this mess however are the H.O.U.Ses... which are spoken of in legend and only rumored to exist. Much to Westley's horror however as legends in fairy tale stories often do come true, so did this legend come true. Further testing of Buttercup by the beta customers swiftly revealed that the fix he had been given by Vizzini did not truly solve the problem and was indeed an H.O.U.S (Hotfixes Of Untested Stature)!

So Westley once again was forced to call Microsoft and this time having conquered Vizzini he was finally allowed to talk to the man who could truly solve his problem... Humperdink!

You see ultimately Humperdink was the guy responsible for creating this whole mess in the first place by creating the bug in the Microsoft component that was causing Buttercup to go haywire, and only he was capable of fixing it correctly. Humperdink is quite an angry bitter fellow who puts on a very tough exterior and at first refuses to solve the problem claiming it has to remain for "backwards compatibility" reasons. This of course is a ridiculous excuse, and after significant verbal posturing by Westley about a duel "to the pain", Humperdink crumples like the girly-man he really is and concedes to create a real fix for the problem.

So Westley's long and grueling quest is now finally at an end. He gets the hotfix that he desperately wants and deserves applies it to Buttercup and the two live happily ever after having a life of riches and luxury.

Although the Microsoft style can be arduous and time-consuming, at least it is modeled after a movie that I truly love. Other companies fall far short of achieving even that. A certain COMPONENT vendor (who shall remain nameless) for instance appears to me to have modeled their support experience on a foreign language adaptation of Dumb & Dumberer. It's like somebody took something that was already horrible in the first place, somehow made it even more horrible and then made a foreign language version of that even more horrible thing so that now besides being absolutely abysmal you can only understand half of what is being said.

PLEASE! Don't let your support experience be like that!

Do whatever it takes to make your support experience more like this movie:

Wherein you are a total ninja badass capable of turning anything around you into a weapon in your arsenal of tricks you can use to solve your customer's problems!

Codemash 2008 Highlights

noreply@blogger.com (Scott Walker) — Thu, 10 Jan 2008 21:53:00 +0000

Thankfully I work for a company that believes in continuous learning and improvement and was lucky enough to have them sponsor my trip to Codemash 2008. Along with all the really cool presentations on topics across the gamut of technology, there are tons of other fun activities to participate.

If pictures are worth a thousand words, then here are two thousand words to describe the highlight of my experience thus far:

For those of you not "in the know" that's none other than Mr. Hansleman himself rocking out with me on some Rock Band for the 360.

Less Code, But More Ways To Write It?

noreply@blogger.com (Scott Walker) — Fri, 01 Jun 2007 14:51:00 +0000

I would say that I have to agree with Jeff Atwood's recent blog post about writing less code. Too often we fall into the trap of creating overly complex solutions to problems, when all that added complexity is completely unnecessary and furthermore just causes problems down the road. I see this as much more of a problem when you're not doing TDD then when you are, as you have the urge to attempt to solve every wacky edge case that might occur without thinking through if those edge cases are worth handling.

At the same time as Rocky Lhotka so eloquently pointed out and as I have blogged about in the past, we've got more new things coming out of Microsoft to be excited about then at any time before. So how can we reconcile writing less code while at the same time having many more tools to write code in? Any thoughts?

Why it's A Good Time to be a Microsoft Developer

noreply@blogger.com (Scott Walker) — Sun, 15 Apr 2007 21:07:00 +0000

I was doing my usual daily check of what interesting new ideas all the creative people on my blogroll are coming up with when I came across an interview with Ray Ozzie, Chief Software Architect for Microsoft. I didn't know much about the man until reading this piece, but I can tell you that from now on I'll be listening to see what it is he has to say. There were some really great questions in this interview, and some even greater answers!

Aside from all of the really cool stuff coming out of MS right now, with this guy at the healm I envision only more great things to come that will allow us to write great apps for our customers. If at the end of the day that's not why you're here then you're in it for all the wrong reasons.