Diagnosis vs Design

This is a subject close to my heart, and my abilities too.

I am ok at diagnosis, but by no means a ninja - and sometimes as a solution architect you're going to need to diagnose a problem. Some are easy. Some are not.

I am from the design school of systems architecture which means doing it right in the first place. I can hold court on OO design til the cows come home, and I can design you a domain model that will model your system's data and - most importantly - its behaviour. Cleanly, concisely and to the point of your requirement.

I can do this across a huge range of technologies - web front end, Sitecore, Kentico, WCF, ServiceStack, Biztalk, MSMQ, SQL, Oracle. The building blocks of a lot of .NET solutions.

What I'm not so good at - compared to the above - is diagnosing where and how things are going wrong in an existing solution. I tip my hat to a select few who can do this better than me.

I can diagnose things that are wrong to a certain degree, and you can and should too. Today I had to sort out a non-working ASP.NET app. Here's what I did, in 10 minutes: -

• Installed the IIS6 metabase compatibility components
• Ran aspnet_regiis /i to install ASP.NET
• Set the App Pool's identity to Local System
• Set permissions on folders

This got the guy going, and I revelled slightly in my ability to spot what was wrong and correct it.

But problems I've seen in the past (and recently) have been a whole lot hairier and have required more tools, and more knowledge.

• .NET Reflector - this thing is a life saver in so many situations. What does this DLL do ? Let's find out..
• SQL Profiler - now this one I do know well. What's being sent to the server ? Answer in confidence. SQL Profiler is your friend
• ANTS Memory Profiler - nice, but a bit bloated. Handy, but the daddy is...
• WinDebug - see the Matrix as it truly is. Here is where your memory is being allocated. And why

I'll tip my hat to some colleagues of mine past and present who can do this diagnosis phase of systems engineering way better and quicker than I can: -

A guy I knew at Datacom who showed me The Way regarding debugging a live app using WinDebug

Another guy at Datacom who worked for me on an app of unfathomable architecture, and is the only person I know to date who got WS-AT working over MS DTC. We spent a pleasant evening, actually entire day and  night, debugging a WCF sync service that if I'd had more say would never have existed.. another story ..

A person I work for now, who can cut razor-like to the cause of and solution to many problems using the weapons in his arsenal, which are mostly Reflector but he also brings his networking knowledge to bear on things I don't get. Like Nick, an awesome troubleshooter

Working with all of these dudes has humbled me when finding problems. These guys can pick the bones of a solution to the n-th degree and tell me what is and isn't right.

I can do this to a degree, but I think I have a different mindset. I design. I usually do it well.

Both skillsets are needed when doing big stuff. 

Which are you ? Can you do both at the outer edges of ability ? I'm not sure anyone can.

StructureMap usefulness

Yet again I find myself spending literally minutes of my life trying to figure out why something is going wrong, only to find a useful feature of something that could potentially save many more minutes; time better spent writing unit tests, for example, or lolling around the coffee shop talking about stuff.

Turns out in the end I'd configured the wrong repository name. Dumbass mistake of the kind we all make from time to time, but one of those cases where the wood is clouding the view of the trees in the way woods always seem to.

I'd done this ..

instead of this..

Note "EmployeeRepository" instead of "LookupRepository". For clarification, LookupRepository wasn't yet finished.

Upon trying to resolve a reference to IEmployeeService, StructureMap was throwing Exception code 202 - "No Default Instance defined for PluginFamily IEmployeeRepository". Confusing at first, turns out I was of course staring at the obvious problem all along.

Trying to replicate this was a pain as it was a case of fire up unit test; get to point that fails; fail (repeat).

Now I'm sure you've come across the ObjectFactory's "WhatDoIHave" method - which dumps out the state of the container, and what resolves to what. It's a useful way of pinpointing anything that doesn't have a concrete type defined for resolution. However, this chap is even more useful: -

Rather than having to get to the GetInstance method of StructureMap to find out you have a configuration problem, you can instead call this after ObjectFactory.Initialize, and it'll run through the map and attempt to construct everything it can.

I wouldn't recommend this for production release, but while in build it could save you at least one cup of coffee. And that's a good thing.

StructureMap is great. So much nicer to use than Unity. Feeling the love :o)