Why we do what we do

I had the fortune of trusting my gut instinct today and watching the Geoffrey Moore talk on innovation at the Business Of Software 2009 conference. I would not typically embark on watching something that feels "soft" as contrasted with the "hard" technological video of my last post. As an aspiring software entrepreneur, I would be a fool to avoid the knowledge that I couldn't otherwise learn except through painful experience.

During the speech, Mr. Moore talks about why good engineers are good at what they do and why they do it. What he said hit home in a big way given the past few days at the office. Engineers, according to Mr. Moore, are committed to solving the problem put before them, regardless of what solving that problem will mean to the business. I was just coming to the same conclusion in light of the fact that I spent the past two days solving a worthy problem without giving thought to why I was going through all the trouble. Sure, the problem had been assigned to me. Sure I had carte blanche to come up with a solution. Sure, the solution could potentially see life in my current project.

I attacked the problem with an excitement I rarely feel. It was a brain teaser and the path to the answer was full of ups and downs, but even as I was half way through I knew that I would succeed if I just pressed through it. So I did. After a day's worth of programming, I had my answer. It worked and I tested it back and forth until I was happy with it.

Then I had a few minutes to think about how I was going to use this new piece of technology. That was when it hit me. I was solving a problem that didn't need to be solved. This wasn't the right solution for the problem we had. It was a solution. My manager and I were both interested in it and we both agreed it posed an interesting challenge, but it introduced a large amount of risk for the small reward of not having to write a few lines of code. So after some thought, I approached my manager and explained that we should take a different direction. One that would not require solving any challenging problems. It would simply require a pragmatic approach and a few dozen lines of that plumbing code we hate to write.