Tools of The Effective Developer: Customer View
A post on Jeff Atwood’s excellent blog inspired me to write up the fourth element of my Tools of The Effective Developer series. This time I’ll handle the habit of taking the customer’s view.
Jeff states that the primary responsibility of a software developer is not to write code, it’s to solve the customer’s problem. (Otherwise, using my definitions, he is a programmer and not a developer.) This calls for the habit of taking the customer’s view in every step of the development cycle. Make it a habit to ask yourself the question: In what way does this matter to the customer? This simple question is like a good friend of mine. It’s stopping me from making costly mistakes and helps me focus on what’s important. Like getting the right things done, and not just things done right.
By taking the Customer View you help preventing technology-based decisions. I once read a report that was going to be the basic input for a decision to replace a legacy system. The author’s main reason was to have an object oriented system. Why would this matter to the customer? While there are perfectly good reasons to have an object oriented system, none of them could be found in the report. Nor could any of the really valid reasons, like usability and functionality issues.
The report-writers obviously didn’t take the customer’s point of view, but the decision was made none the less. So what happened you ask? Still not finished, many times the initial budget spent.
Being able to look upon your work from the customer’s point of view takes empathy, the finest characteristics of them all. Exercising it regularly is something all of us should do. That’s why I like the habit of taking the Customer View.
Here are the other posts in my Tools of The Effective Developer series:
Too few software developers have empathy for their users, it is a common problem. They ‘code’ what is easiest, not what is correct. IMHO, we build tools to be ‘used’ by people to manipulate data (which possibly solves their problems, but probably not), we don’t actually solve their problems for them, nor are they always the ‘customer’.
Amen brother!
BTW, I love your weblog.
I agree entirely.
The need to consider the customer’s view is something built into methodologies such as SSADM (launched in 1981), which although targeting older procedural languages and arguably a little dated, nonetheless has a lot to teach modern developers in terms of “core practices”.
The problem is that developers (it seems) rarely heed the lessons of the past, perhaps because we are fixated with what’s new and not what history can teach us.
Exactly! And we are so focused on (new) technology that we even try to bend our customer’s needs to fit it. Been there, done that!