Troubleshooting: Simple Stuff First

I spent a lot of years running and fixing radar systems on big airplanes while flying around cool places like Iceland, Saudi Arabia, and Alaska.

One of the hardest lessons I learned (or had beaten in to me by crusty old sergeants) was that you always, ALWAYS look for the simplest solutions first when troubleshooting.  In my early years I was always diving in to the books to pull out the four-page fold out schematic instead of first using some elementary deduction to get some quick checks out of the way. This same principle carries directly over to ANY form of troubleshooting, not just trying to figure out why dots aren't appearing on a radar screen.

Today I had a good reminder of that when trying to figure out a problem in a system we built.  Custom security roles weren't being recognized by one component which maps records in a database table to business objects based on an enumeration.  I jumped into the debugger and started stepping through the component where the disconnect was (sorry, no test around it, and it had been months since I'd been in that part of the code).

I quickly found this wasn't the best use of my time, and instead went to a very rudimentary step: double-check the values in the database.  Some close examination immediately led me to the source of the problem: someone had added spaces to the role name in an attempt to make them more readable.  "UserType" became "User Type" and "BusinessFunction" became "Business Function".  This may look nice for humans but causes some issues in code...

That quick check saved me from losing more time in the debugger trying to wind my way back to where that initial comparison was happening.  The simple thing won out over the more complex thing.

We geeky types like solving tough problems and too often we get carried away with looking for the harder answer when the simple answer is sitting right in front of us.

(On a related note, if you haven't already, grab a copy of Debugging by David Agans and read through it several times.  Highly worthwhile to help polish your troubleshooting skills.)

Any Wrap up of CODODN I Wrote Would Suck Compared to...

Andy Erickson's video summary.

'Nuff said.

MVP Summit Wrap Up

Like Nino, this was my first summit even though I've been an MVP for three years.  I spent most of my time in SharePoint sessions; however, I sat through part of the C# Language Future discussion (my head still hurts) and a wicked cool glimpse into Rosario (VNext of TFS).

I hooked up with a lot of old friends and made a lot of new ones while I was there -- and spent a LOT of time talking with Jef about a lot of important things for building a great development team such as culture, doing agile right, etc., etc., etc.  Seeing Keith Elder get on stage and sing karaoke (and break the process) nearly paid the price of admission for me.  I also got to meet Roy Osherove and Oren Eini (Ayende) which was great because both them helped me out with the book.

I also had a couple nice chats with Ben Curry who I met at SharePoint Connections in Las Vegas last November.  He's a wicked smart SharePoint MVP with a lot of experience in huge-scale SharePoint jobs.  I can't wait for his book on SharePoint Best Practices to come out.  Additionally, I met Eric Shupps who is one of several folks I'm working with on a cool SharePoint project -- more on that when things gel.

Perhaps the funniest thing about the Summit was sitting in a session on Excel Services while I was IMing back and forth with Phil about a problem we were overcoming.  I'm heads down with Phil confirming our approach, then look up and see a demo using Excel Services -- and see a solution to the exact problem we're working on.  The ES team dev who built the demo was in the back of the room, so I grabbed him after the session and got some validation that we'd identified all the issues and were solving it in the right way.  That was worth the entire trip out to Redmond!

One thing that struck me about Microsoft's attitude in nearly every session: they are actively seeking feedback from the community on current features, planned features, and general pain points I mean "opportunities."  I will (and do) bust Microsoft's chops on any number of issues, but the effort they're putting in to changing their culture is amazing.  I was part of some tremendously productive conversations with the Visual Studio team, and listened in as the Really Smart SharePoint folks conversed with any number of different MOSS team folks.

Overall it was a great trip and I'm looking forward to the next summit!

(Oh, and my Tweets went from four to 70 in one week...)

CodePlex Session at MVP Summit

Sara Ford and some of the CodePlex gang will be putting on a session around where CodePlex is going.  They're putting the session on at the Sheraton Hotel Seattle - Queen Anne Room on Thursday, from 2-5.

Stop by if you're interested in seeing the future of CodePlex (or getting loads of swag)!

Dropping Testing is Not a (Viable) Option

Yesterday at the opening of the MVP summit I spent a bit of time in an open spaces session on testing practices and pitfalls.  I left after the conversation took a turn where a number of folks were seriously talking about dropping testing in order to meet deadlines.

This from supposed industry thought leaders.  Frightening.

The conversation started out with someone putting forth their historical data that testing adds 10% - 15% to schedule time.  The person with these metrics then said it's an acceptable business decision to cut out that testing if your deadlines are in jeopardy and you need to hit milestones for time to market, compliance, business drivers.  I became more and more dumbfounded when others piped in and agreed.

This is sheer insanity.  I was so appalled that I couldn't bring up a coherent counter-argument to this lunacy.  Dropping testing to meet a deadline is like cutting off your leg to make a weigh in for your weight loss contest: sure, it's an option, but it's one which ought to be rejected by any rational person.

We've all worked with deadlines, and anyone who's worked more than .0432 projects has undoubtedly hit scheduling problems.  Doing poor quality work to meet that deadline never, EVER gets you in a place where you want to be the day after that deadline.  Sure, you may have gotten a release out and beat your competitors to market, but you're screwed after the first 100 people download your software and find it's rife with bugs.

(I'm purposely leaving off discussion about the design goodness that comes from Test Driven Development or Behavior Driven Development/Design.  I can't have this post going over 500 pages...)

The right answer when you're having milestone or deadline issues is to cut scope, not cut quality.  Furthermore, scheduling problems should be identified very, very early in the project -- you're using some form of feature velocity tracking, hopefully, which will let you discover issues early on.

Those scheduling problems/issues/challenges need to get communicated to the client (internal or external) immediately, along with your mitigation plan.  That mitigation plan can never, ever be "we're going to cut quality to meet this deadline."  Instead, that plan should be "we're working to close the schedule gap, but we need to have a hard look at what scope you want delivered for that release."

One of the best discussions I've ever read about this is in Tom and Mary Poppendeick's Lean Software Development.  They talk about a state government project that had a release date mandated by law with a set of functionality also mandated by law.  The project was also biting off a bunch of other functionality. 

The project was failing and had no chance of hitting the milestone when Mary came on board.  Her first triage was to cut out work on all features that weren't directly tied to those mandated features.  The project team worked only on functionality that was required by law since that had to be part of the release.  Everything else was shoved off and worked on after they hit that deadline.  They met their deadline, not by cutting quality, but by doing a brutal cut of features which weren't absolutely necessary for the release.

Cutting scope for a release isn't ever an easy conversation to have with a client, but it's a necessary one.  Furthermore, that conversation is easier if you have it very early in the process, not a week before you're due to ship.

Cutting scope is a reasonable way to hit your deadlines.  Cutting testing is not.

Breaking Apart Excel Files with Beyond Compare

I'm working on a SharePoint project using Excel Services to host an Excel file our client's sales reps use to create a total cost of ownership sales report for large equipment.  Excel Services is perfect for this except for one detail: You can't have images in the workbook you're serving up with ES. 

Think sales reps and sales reports.  They need images.  Bummer.

No worries, because the new XML format of Office documents lets us crack open those files and programatically inject new content or edit existing content.  The changes aren't overly simple, but they're workable using a combination of the System.IO.Packaging class and some manual edits of XML files.

Before you start cutting code, you need to figure out what you'll need to edit.  Two tools come in handy for this: Beyond Compare 2 and HTML Tidy.  Beyond Compare does an amazing job of directory comparison, and Tidy lets you quickly format XML files into an indented, readable view.

You'll also need before and after versions of the Excel file.  We cleaned out images from the workbook we were hosting in ES, uploaded it, then ran it through our system we've built, and finally saved a snapshot of it.  Then we opened that imageless snapshot, added in our images, and saved that file as a separate file.  Rename both with a .zip extension, extract them to separate folders, open those folders with Beyond Compare, and Poof! you've got an exact view of what you need to update in your files.  (Note the blue and red ".bak" files on the left are my additions as I'm working on coding up the changes.)

You can use Tidy to help clean up files on both sides of the viewer for easy readability.  Just run "tidy -im -xml <sourcefile>" to get a nicely formatted file.  "-xml" treats the input file as XML, and "-im" indents the XML and updates the source file rather than outputting to a separate file (which you can do).

Now when you do a comparison on files you'll get something like this showing the exact changes:

Now it's just a simple <koff, koff> matter of coding up the edits and additions to those XML files.  More on that later.

Now Playing: Mike Farris -- Goodnight Sun.  I've been all over Farris's "Salvation In Lights" for its great vocals and music.  This earlier album by him is full of amazing tracks, to the point where I'm starting to get concerned I'm wearing out the tracks and sectors where its located on my iPod...

Central Ohio Day of .NET Nearly Here!

The Central Ohio Day of .NET is next Saturday, April 19th!  Mike Wood has posted up the schedule for those of you interested.

I hope to see you there!

Looking for .NET Work in Chicago?

Quick Solutions, the company I work for, has just gotten a number of opportunities for .NET developers in permanent positions in Chicago.

Contact me via the sidebar link if you're interested!

Post Visual Studio Uninstall of SQL Express

On occasion I've someone I know has inadvertently installed SQL Express as part of the Visual Studio install, after having already set up a development machine where the real SQL Server (whichever flavor) is already installed.

Running the VS install again and looking under the Change/Remove Options won't help you remove SQL Express in this case.  Instead, head over to Control Panel's Add or Remove Programs section and you'll find the listing for Microsoft SQL Server 2005.  It's not clear from the screen, but clicking Remove here will give you an option for which instance of SQL you want to remove: SQL Express or the "real" SQL.

A couple more clicks of "Next" and "Finish" and poof! SQL Express is gone.

Fixing Oddities in Omea Reader

I use Omea Reader for reading my blog and newsgroup lists.  It's free, it's handy, it's powerful, it's offline so I can read my blogroll while I'm driving back and forth to Columbus for work.  Just kidding, folks.  Really.

A couple weeks ago all the lists in Omea's views and feeds lists showed up as duplicates.  Ugh.  Furthermore, the "Unread" view flat out wasn't working, meaning I needed to troll through a whole lot of junk when I just wanted to see new posts.  Ugh.

Easy fix: run "dbrepair.exe" from Omea's folder under Program Files.  First back up your Omea files (local data folder in your user folder), then run "dbrepair.exe /fix" to repair any busted links, clean up the indices, and do a lot of other general repair.

Poof!  Everything's back nice and shiny.