Sunday, September 6, 2009

The Curse of Knowledge

I'm currently listening to an intro to psycology course lecture series and during a lecture on intelligence, the speaker mentioned "the curse of knowledge" (it's lecture 12 in this series ocw Brain and Cognitive Sciences. This is the problem caused by a difficulty in seeing the perspective of someone who DOESN'T know it.

This means that when I'm describing something to you, I inherently assume you know what I know. I have to consciously stop and think to try and figure out what you may or may not know and develop an idea about how to present what I know in a manner that you will be able to understand. It turns out that this is often difficult, especially if you have a LOT of knowledge about a specific subject. That is not to say it's impossible to see things from the ignorant party's perspective, but it requires a conscious effort to change perspective.

I see this all the time and it is particularly evident where I'm working right now. We have a fairly complicated set of software components that are used to do some fairly simple things (that is a whole other story). When speaking with the folks who built the fairly complicated things, many of their explanations are littered with assumptions about what needs to happen based on their inherent understanding about the inner complexities of what was built. As we get further away from the people who built the system, the assumptions begin to shift to people who have NO IDEA about the inner working, but have VERY GOOD ideas about what the software is supposed to do. These two camps are separated by a VERY wide chasm of knowledge that is NOT shared by both sides.

My current task is to get developers to divorce themselves from their current perspective and start looking at things from the perspective of their ultimate customers and how the software is valuable to them. Nobody outside our team really cares about the inner workings of our software, but we're so focused on these details that we've essentially misplaced our priorities. I feel this is causing friction because we are doing a WONDERFUL job of building software, but I'm convinced that we are building WONDERFUL software from the perspective of someone who wants to build wonderful software, not from the perspective of someone who wants to have a wonderful solution to a business problem.

Overall, the "curse of knowledge" has many implications outside of software development, here are some other links I found interesting on the topic.
http://37signals.com/svn/posts/213-the-curse-of-knowledge

1 comment:

matthew said...

I think the issue of creating wonderful software versus creating a solution to a business requirement is a very common problem. We're part of a group of individuals that generally enjoy the art of creating solutions of varying depth: quick & dirty and all encompassing systems knee deep in features and robustness.

One of the (many) pitfalls to this gig is the need to stay on top of the latest languages, tools and techniques; I have dubbed this the new and shiny syndrome. I have this disease although it's entering a period of remission.

So the question is, how does this happen? Easy, we're simple creatures and learning a new ORM API can feel more rewarding than debugging a shopping cart transaction or inventory report.

Another great post, several great nuggets in here... I could have written a novella of a response. Also, if you're not able to re-orientate the mindset... a large poster with the phrase "The beatings will continue until morale improves!" will work wonders.