Evaluating Alternatives vs Reacting To Differences

Have you ever noticed that we tend to “evaluate” new products and services through the perspective of the existing products and services that we use? We compare feature implementations and making judgements on whether or not the implementations are the same or better than what we are used to. We have a tendency to react to the differences that we encounter, because those differences are … well… different than what we are used to. We tend to not see the product or service we are evaluating, objectively, because of this.

An example: IRC vs Campfire

At my previous job, we used various forms of communication to stay in touch, all day every day. One of the things we used was a private IRC server. It let us have real time chat with the entire team to share information, ask questions, provide links to interesting stuff, generally chat and joke around, and more. We also used our IRC nick names to provide a status that others could easily see. For example, my usual nick was “derick”, but when I was out to lunch I would change it to “derick_lunch”. Or, when I was just going to be away from the computer for a few minutes, i would change it to “derick_brb” (be right back). This system worked well.

Then a few weeks before I left, we decided to try out 37Signals’ Campfire as an alternative to IRC. I don’t remember what reason we had for wanting to try something different, but we decided to give it a go and see if it would provide what we wanted and needed, and if it would provide for those needs better than our IRC server. We also decided that if we were going to evaluate it, we would use it solely for at least one week – no IRC, just Campfire.

You want to know what the first thing I thought was, when I signed in to campfire? “How do I change my nick name?”

And it wasn’t just me… the entire team immediately reacted to the different environment by comparing it to the one we were used to. There were a number of IRC based features that we all liked, that were not available in Campfire, and it annoyed us. But, we said we were going to use Campfire for at least a week and see what it could do for us.

Evaluating Solutions To Problems Instead Of Feature Implementations

After a few hours of us not sure what to do with ourselves inside of Campfire, I realized what we were doing and why this wasn’t a fair evaluation of the system we were trying out. I also realized that a better approach to the evaluation would be to look for the root problems that our IRC server was solving for us and then look at Campfire from that same perspective: how does this tool solve (or not solve) these same problems?

After a little bit of thinking, we recognized one of the fundamental problems that were were solving with IRC nick names was just knowing whether or not people were available. We wanted to know if they would respond to questions immediately or a little while later, etc. It didn’t take long for us to also realize that Campfire didn’t support any kind of status (that we could find, anyway). We wanted to use Campfire for what it was good at and find other solutions to the problems that it didn’t solve, though, so we stuck with Campfire for general chat and decided it made sense to use our instant messenger status instead. The IRC clients were already good at setting an away status on being idle, so we used that to indicate we were away because it already did that for us. Several of us also set up custom states, such as “Out To Lunch”, etc.

By changing our perspective and identifying the problems that we were trying to solve instead of just comparing features, we found that most of the features we missed in our IRC server were able to be replaced with solutions to the actual problems via another system. There were a few cases where we simply couldn’t find a suitable solution to the problem via another system, but I think those were few and unimportant.

In the end, we used Campfire for nearly two weeks instead of just the one that we had planned, before switching back to the IRC server. It turned out Campfire didn’t provide any significant advantage over what we had with IRC, so there was no need for us to spend the money on Campfire. We did, however, decide to keep some of the other decisions we made in solving our problems. For example, we stuck with the instant messenger status instead of using IRC nick changes.

A Better Perspective

Overall, I’m glad my previous team took the opportunity to evaluate Campfire. I now have a good idea of when and where this system would provide value to a team. More than this one product, though, I was able to take a significant lesson away from the experience and realize that I have a tendency to react to change instead of evaluate the change against the problems that I need to solve. By approaching new systems, new technologies, new processes, or anything else with a perspective of “How does this solve (or not solve) my problems?”, I’m able to see value and benefit in places where I had previously only reacted to something being different.

… On a related note: I’m trying out MacJournal for blogging from OSX. I’m honestly having a hard time with it compared to Windows Live Writer – specifically when it comes to styling the text the way the LosTechies blog is styled. I don’t know if I’m going to end up with the right headers and section styles, or something completely different than my normal style. We’ll see once this is posted. It turned out awful. I had to go into the site admin section and manually edit this blog post to get things anywhere near normal… it was just one big blob of text with no line breaks before I edited this… but I’m trying to approach MacJournal with the same perspective that I’ve just described. We’ll see if this product actually does provide solutions for my blogging needs.


Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Pragmatism, Product Reviews. Bookmark the permalink. Follow any comments here with the RSS feed for this post.