The Code Whisperer

In Rapid Development, Steve McConnell talks about friction between these two parties rather than relationships in general. Friction implies some degree of animosity and detrimental effects on a software development caused by developers and customers communication aren’t always as a result of disagreement. To be honest, and with one exception I’ll come on to in a minute, I think generally developers and customers should be kept as far away as possible, unless there is a chaperone. With massive generalisations, so there will be exceptions, here are my reasons:

• Developers speak another language, so do customers. Neither can accept why the other doesn’t understand so you need an intermediary that can speak, or is willing to lean, both languages and translate. I’ve just had a very good example of this where I’ve spent nearly an hour on the phone over the last week helping a customer buy and download our restoration software. He uses the computer as a tool and the vagaries surrounding accessing a hyperlink in an email is of no interest and outside his area of knowledge. Repeatedly stating “click on the link” isn’t going to get anywhere
• Developers like creating new, exciting applications. Having to make changes is viewed as mundane and bound to be met with derision and much tutting
• A 3 month development is short for developers but a lifetime for customers, particularly if they have seen a perfect prototype. Software people know that an application is like an iceberg with the GUI above the water and most of the code below, but customers focus on the bit they can see
• If a customer desires certain amendments to an application that is being developed that is time consuming to include, if the developer makes the decision to include it, this may be made without considering the scheduling or financial implications of doing so
• Ideally developers should not be the first line of support as this causes interruptions and also different categorisation of problem severity. The customer may class a problem as high severity as it’s reducing their efficiency, but if the developer sees it as a tricky or dull change the severity may be reduced. Conversely customers often see all problems as top priority and want them fixed immediately

There is one exception. I strongly believe software is better when the people designing and building it have some knowledge of the business or industry it supports. I worked for British Telecom just after privatisation and the day I spent looking at different sorts of exchanges was one of the most useful days I have had. All of a sudden the huge billing system I was working on made more sense. Just knowing some of the language the engineers used on a day to day basis improved the quality of my work. Arrange days out of the office for your team and immerse them in the business they are producing software for. They will understand the customer requirements better and will benefit from a day away from the office.