Send As SMS

Wednesday, February 08, 2006

Developers who don't talk to customers

If they did, software, may take longer and be more expensive - according to the tri-angle but it would be right. Attention would be paid to the areas that the customer cares about. I'm not saying software should all be pretty interfaces and no back end, but it should encompass the features the users will find useful. This isn't a new idea or particularly insightful but it's one that developers seem unwilling to accept. Spolski wrote a great quote, "Stop expecting customers to know what they want" Which is true, I often develop an idea then go to the user and see if it's on the right line. Customers can't express the right technical ideas regarding their requirements and since engineers loath the opportunity to write decent specs. More importantly nobody refers to them after writing two sides of drivel sans any diagrammatic expression of the problem. Without understanding system they are modelling it ends up the model is wrong. Users believe it is the system's fault, to anthropomorphise for a moment, the system isn't wrong and it's not fair to accuse it. It's the designer that was wrong, the coder, the person who wrote the spec the person who thought up the model. Now you can expect some paradigm shift from clients, they will accept some change but you can't re-write their understanding of the problem to make your 'incorrect' system is the solution. This vitriolic rage comes from an online testing system I am currently involved in. The designers have given all manner of useful elements on the interface, how many computers are connected how many tests are taking place how many results are left to be sent to the marking server. However the board who have designed / spec'd this haven't considered the whole exam process, nowhere is there a mechanism to allow extra time, basic principles forgotten. They've assumed the servers infallible and assumed a 100% up time, which given that their servers are running on goat power, in a field, in Bosnia - and it's winter, it isn't a great assumption. I feel this sometimes comes from a lack of passion. You can't be passionate about everything but if you can't even fake it in a "Harry met Sally" kind of way you won't produce a good product. If you can't get it into your head that you want this product to be good, neigh great or better than great it won't be and the users will know this and see this. Then the users won't use it and it will all be pointless. So my call to you all echos someone who is passionate about his products; make your software "Insanely GREAT", get inside your user's head and listen to them.


dom said...

first post!

you do realise the 'average' reader will require a dictionary for every other sentence in that post? :)

2:27 PM  
Mark Cornes said...

Will they, example svp ?

4:12 PM  
dom said...


also splitting up into paragraphs would be nice :)

good start though, looking forward to the next post

10:07 AM  
Mark Cornes said...

paragraphs... you'll be lucky...

9:45 PM  
Pepperpot said...

It's the designer that was wrong, the coder, the person who wrote the spec the person who thought up the model.

I think you are flagellating yourself a bit too much, M. True, it's incumbent on the designer to produce a system that can be used by the real people doing the job, not an idealised 'person-unit' who is a perfectly predictable component of a perfectly predictable system.

However, it's also the customer's responsibility to understand the task that they want automating at more than a superficial level. It's her responsibility to understand the subtleties of the way the task is carried out on a day-to-day basis with all the human frailties that implies.

The problem may rest more with the inability of the customer to articulate subtlety, and the programmer to 'hear' what is being said. Especially as neither wants to look thick.

Maybe there is scope for a new profession - IT needs advocacy?

10:16 AM  

Post a Comment

<< Home