Sometimes you get the bear, and sometimes the bear gets you. When we see an inspiring wildlife picture of a bear with a salmon in it's mouth, it's very easy for some of us to relate to the bear. This is the mental model we have in our heads of our role in our environment. But often, we're the salmon, not the bear, and when that happens, the swim doesn't quite seem like it was worth it.

There are several lessons we've all heard countless times, and that most of us intuitively understand. In work settings, I routinely try to practice these lessons. But in my personal life, I sometimes find how easy it is to try to take shortcuts... and when I do, I find I re-learn again why key practices are so important, as I have over the last several months:

• Always seriously consider more than one alternative, and choose the simplest one you can that meets your needs
• Look before you leap, and make sure you're ready
• Manage change, so that the effects of those changes can be well understood
• Always have an exit strategy

Recently, in some personal projects, it seems like I've been bear eats more than I've had salmon meat, at least in regard to one of my hobbies - being an early adaptor for emerging computing technologies. There have been two such episodes in my personal life in the last few months that are worth sharing in this regard, and that have reinforced the importance of the above principles. I'll go into quite a bit of depth about where problems originated, and the pain I experienced in trying to isolate the problems in the absence of good information. Hopefully, lessons from my experience will be beneficial to others designing similarly complex systems and service offerings in the future.

The first lesson is presented in detail elsewhere on this site, and discusses my painful experience with attempting to use Xbox as a media extender and cooperating component with Windows Media Centerunder Vista. At the end of that journey, after 8 months of difficult and frustrating troubleshooting, I ended up abandoning my original plans, and picked a different path than I originally had pursued. I should have given this alternate path more careful consideration originally, but was enamored by technology solutions, marketting, and a hope to save money, rather than pushing for a better architecture for my problem, and making a realistic appraisal of the risks involved. While there were many problems with other components, at the end of the day, I solved the problem myself by working around it, rather than continuing to wait on the solution I had been expecting others to deliver me. In hindsight, my revised approach has more value, and was not really much more expensive than the original concept. The perceived costs savings I was originally hoping for look pretty minimal, after all the time I've had to put into troubleshooting.  Often, when you've invested money in the original solution, and develop a mental model that you can conquer any problem, you can really end up spending lots of money and time getting things to work. The lesson I've re-learned here is there is really no shortcut to having a robust and effective design.

The second 'meal' which I participated in occurred as I was evolving the functionality of this site. Since much of this functionality is based on open-source components, with lots of tweaks and regular evolution of those components from the community. In this environment, it's very easy to get into a mode of always wanting the next improvement, without considering carefully if you really need it. Having the latest and greatest sounds compelling, until something breaks, and you have to try to fix it.

It's easy to work yourself into a false sense of security in installing new updates or changes, without testing each of these changes independently, if things go smoothly. However, serious problems can occur if you allow yourself to incorporate several components that aren't themselves quite working, and suddenly the whole system stops working. If you've only changed one thing, you know where to look. If you changed just about everything, you have to suspect everything when nothing is working, or things are working in surprising ways. Working your way out of that situation can take a lot of time, but as long as you have a roll-back solution, things aren't too bad.

This site is a hobby for me, and I'm usually not too interested in routine and boring maintenance tasks like making sure the backups I have are working. It's a pain to maintain a separate test site, load the software and databases and keep them up to date, and ensure that a realistic set of conditions is run before releasing a fix to the production site. I is easy to fall into the trap of believing you don't need that 'extra' stuff; I work on the site myself, and I tell myself that I know what I'm doing. What's the worst-case scenario- I can just roll back to a previous version, right?

Well, over time, I developed a habit of making lots of such changes, without having a good trail of all the operations I actually had done, and got myself into a complex dead end which didn't work, and which wasn't easy to undo. Unfortunately, when I went to use my backup, I discovered that it was corrupted and not usable. I then discovered the server backups from my hosting company only went back 30 days, and since I hadn't been giving much attention to this stuff, it had been longer than that. My only solution was to go through a painful process of building the site from scratch, and migrating and validating each of the database tables (there are over 100) manually - not a fun process.

So often, we want to believe that our personal brilliance, tools, innovation, and leadership are the difference between success and failure of an effort. It's much harder to admit that it's often more likely the result of discipline, persistence, clear thinking, and basic hard work.  I really am disappointed with myself when I've shot myself in the foot such as this. When such circumstances are my own doing, the injury seems to hurt more, and frankly is embarrassing! The real journey of discovery for us to make is when we can realize that mistakes we make are usually rooted in failing to do the really important things things, and that getting sloppy, losing focus, shotgunning, or just trying to take shortcuts is not a sustainable strategy.

So now, I have a new test site (with a different color and theme, to avoid confusion about which version - production or test - I'm working on), and I have created two checklists to remind myself of the things I pretend to know, but far too easily forget - one for releasing new functionality to this site, and another for performing upgrades to my computing environment. These won't help my feet to heal faster, but it might keep me from re-injuring them the next time I go into the wild!

Lessons such as these are only really learned if they are critically examined, effectively communicated, and serious considered. Ideas stick with us through stories and experiences, and when information surprises us. Hopefully, some of the above experience will do that for someone else.