The following excerpt is from a Pragmatic Programmers podcast with Robert Martin. The discussion is about Agile development, but I believe it applies to any software development work.
We have a lot of problems with Agile..The one that you just mentioned is one of them. There are programmers that don’t want to talk to customers, they just want to write the code. There are also customers that don’t want to talk to programmers because programmers are not the easiest people to talk to and customers tend to be busy and in some cases customers believe that the management of detail is the programmer’s job, not their job. So we have a disconnect in the industry where we try to do Agile development but to do Agile development requires programmers that are willing to talk to customers to understand the business issues and business people who are willing to talk to programmers and understand .. not the depths of the technical problems but some of the technical issues. Until we can cross that bridge we’re constantly going to have this problem.
…
But tools like this also miss the point. The problem is that business people believe that the management of detail is the programmers job and there is no way for a Business person to write a Cucumber test or a Fitnesse test without getting into detail. That’s the bridge that we’ve got to face somehow. Business people have to realize that there are details… not all of the details… but there are details that they have to deal with and the programmers are exactly the wrong people to have to deal with those business related details. Business people say it just makes common sense, just make the web site work. And the programmer says I can make it work by doing X and the business person is surprised a month later when he sees X on his web site and its exactly what he doesn’t want. He goes back to the programmer says you wanted me to make it work. You wouldn’t tell me what to do. So there’s got to be a much better binding between the business side and the technical side. Some people have tried to this with another layer – the business analyst layer, who is supposed to sit between the customer and the programmer and act as a liaison and I think that can work but boy or boy what a tough job. That business analyst is sticking is head out in two different directions and either of the two sides can chop it off…. He’s the one that hears from both sides why it can’t be done.
For other than relatively simple Software, the business person or software development customer has to expect to get down into the weeds of complexity to keep a software development project going successfully. This means dealing with the 1% cases and not glossing over the complexities inherent in their business. Software development is not a “fire and forget” proposition. You need to be involved and make decisions relating to the inherent complexity of your business. The point of this post is really as a pointer to a third party expert confirming that issues we come across with our customers are common issues and shouldn’t be discounted. I’ll more than likely have more posts like this quoting a third party expert on a software development matter. Some aspects of Software Development are just so counter-intuitive to the way “normal” business operates that it’s important to emphasize the actual nature of software development using third party quotes.