Though work and family keep me pretty busy, everyone needs a hobby. Mine is online gaming. My current addiction of choice is City of Heroes where my favorite class to play is the Scrapper. Scrappers engage in close-range fighting with the enemy and are good at dishing out damage, which means they tend to go after the biggest bad-guys they can find in a group leaving others on the team to manage the lesser minions. Since this puts the scrapper in the middle of chaos with a limited scope of influence, scrappers often acquire what’s called "scrapper-lock"—they lose awareness of external contexts and miss important developments (like that their own health is in the red and it’d be a good time to pop a health inspiration).

This came to mind recently during a podcast on Dot Net Rocks. In this episode Carl and Richard talk with Udi Dahan about SOA. For all that Udi tends to discuss issues way above my scale enterprise-wise, I enjoy hearing him flog his hobby horse. He has the ability to make complex concepts understandable by using solid examples that relate well to his points.

Near the end of this episode (around 57:08), Carl asks "If there’s one big mistake that people tend to make, what is it?" Udi answers with our tendency to view challenges through the lens of our current obsessions and assumptions. His response reminded me strongly of scrapper-lock. It is really easy to look for solutions in terms of our current abilities and mind-sets. It is really difficult to take a step back and make sure you are taking on a problem in its entire context.

Stay on Target

There are two important factors to achieving IT goals. The first is identifying the target. This is actually the harder of the two factors because we bring so many unacknowledged assumptions to the task. The first assumption that messes us up is that we work for IT. We don’t. We work for companies, universities, governments, non-profit organizations, ad-hoc teams, and ourselves (and a multitude of other entities too varied to name). I tend to concentrate on corporate development so I’ll talk about working for a company below, but you can substitute any of the above just as easily.

In considering a goal, it is important to have not just a complete understanding of the goal itself, but of the reasons behind that goal. This is what makes software development such a challenge, by the way. You could train pretty much anyone to write the actual code. It’s learning to map the code to the needs of your company that causes real strain.

Take, for example, the requirement that you "hit a target roughly six inches in diameter from a distance of 150 feet." Which target did you see?

In this situation, you can ask all kinds of clarifying questions about the target (what color, outdoors or indoors, how much force etc) but the one question that is going to provide the best guidance is "why?"

Understanding the purpose gives you a load of related context that allows you to skip a lot of stupidity and identify buried assumptions. The reason this is so difficult is that in order to understand the purpose, you often have to understand the business (domain, university, non-profit et al) and most IT people resist doing so.

Gearing Up

Once you understand the target, deciding how you are going to reach it offers its own batch of problematic assumptions. Too often, we let our pet projects or obsessions intrude in this process. Are you creating a web interface because it’s cool and what you know or because it’s the best way to meet your business need? Are you implementing a new enterprise framework because the company needs it or because you really want to try out the whole SOA thing?

This is where integrity becomes important because you’ll often find that the best way to go is less interesting than the one you’d actually prefer. Every project requires trade-offs and those can leave you lots of room to nudge things in directions that might offer a slight advantage, but might also just scratch a personal itch to do things the "right" (i.e. your) way.

As the subject matter experts in our organizations, we have a lot of trust. It is easy to abuse that trust unintentionally by allowing ourselves to give too great a weight to our own interests (it’s also easy to abuse this trust intentionally, but that’s another post entirely). This tendency drives many of the fads you see sweeping through software development now and then (Extreme Programming anyone? Some good things are there, sure, but not nearly to the extent many of us convinced ourselves existed).

Acquiring a Strategic Overview

Because lock-in is so easy to fall into, it’s important that we develop some habits that overcome it. Here are some of my ideas, but please add or modify them in the comments if I’ve missed something useful.

• Develop some key general principles. It’s important that these be both "general" and "principles"—i.e. fundamental ideas that are valid regardless of programming environment or language. YAGNI is a good example of a general principle and one of my core tenets.
• At the beginning of any new project, make sure you ask the most important question: why? Further, make sure you understand the answer. It also helps if you take steps to understand your domain. If you program for businesses, for example, introductory courses in accounting and management are extremely useful. I use information from the one college accounting class I took way more often than information from my one college computer science class.
• Periodically review your tools. Is there a new kid in the Unit Testing world that might have some sweet capabilities (and an easy conversion utility)?  Has someone slain the dependency injection demon for Mock objects?
• Periodically review alternative environments. This is the hardest for me personally because I’m rather attached to MS Visual Studio and the .Net framework. Why should I bother with REST or Ruby or Eclipse? The important thing to learn here is perspective and the important perspective is not your own but that of the company (or whatever) that you work for. However comfortable you may be with Asp.Net, for example, it may be that your company can realize a substantial benefit by adopting Ruby. I’ll never forget the roadblock one developer on my team overcame in a day using python that I was afraid would set us back a week.
• Finally, make sure you are aware of and take the time to understand the current crop of buzzwords. Agile, SOA, TDD, Grid Computing, all of these have value or people wouldn’t be buzzing about them. It’s easy to become jaded after you’ve applied your third silver bullet and the slavering monster is still healthy and looking your way. Declaring all silver bullets useless and hibernating isn’t going to help you. When management comes to you with a new solution they read about in their trade magazine, you’ll get a lot farther if you can speak knowledgeably about its strengths and applicability in your environment. And who knows, you may just find something that slays one of your own dragons while you’re at it.