It's funny how it doesn't take software developers long to find out that sometimes clients are a pain. I mean, they don't know what they want, but they do want something, they don't like the boundaries you put around their problems ... they just want you to solve their problems (cheaply, quickly and well).
Robert DW has two interesting articles about this phenomenon, the first is If Architects Had To Work Like Web Designers... and the second is Software is too expensive too build cheaply.
However, if you've ever hired an architect, or a designer (any sort) you quickly realise that it is really hard making up your mind about subjects outside your experience/skillset, but still important to you.
The closest most software developers get to this is when they get help designing their website, or their corporate logo/design. Now if you get someone who isn't really interested in doing a great job, then the process is easy, but the end result is a logo that looks amateurish, or a website that just doesn't bring in new business, or impress clients.
A good designer can be a pain to work with, because they make you think about what you want, educate you about what is good/bad and mostly seem to get you to do all the creative work for them. A great designer reads your mind and does this without hassling you by the sort of mental osmosis that has to be seen to be believed (or maybe they're just plain lucky). Bad designers just give you their best attempt at a design that they think looks 'kewl'.
Pay attention software developers, this is the mirror image of what our clients experience. They ask for a simple order tracking system, and we bombard them with questions about the datatype of an order ID, the scope of a business process and a dozen other questions that they feel (rightly or wrongly) we should already know the answers to (if you're claiming to be an industry expert, they may be right about these).
I think one of the keys to being a great software developer (other than being graceful in the face of difficult clients) is to learn how to help your clients find out what they really want.
Back when I was at uni, they called this needs analysis, and told us young aspiring developers how clients might know what they want, but we were supposed to tell them what they needed. Like a lot of academic advice, that is partly true (a client doesn't always want the right things) and partly bull-dung (the customer is paying you to do what they want). I've put my foot in it a couple of times, telling clients that they needed X when they had asked for Y ... it's bad for business, not to mention rude.
The customer is always right, even when they're wrong. A software developer should make sure that it's not their own incorrect assumptions and biases that are wrong, as often the problem is an ego issue rather than a dumb client.
So don't just client-bash when they don't seem to get it and be willing to take the blame for something you've done wrong, and you're on the road to becoming a better software developer.
No comments:
Post a Comment