While there is much truth in this, I've found that too many programmers refuse to learn even the fundamentals of the subject matter of the business. Many will tell you this up front and without shame. I know many programmers who have worked at my employer for years and who still do not know the first thing about the business.

In my job, I write requirements for others to code, and I write code from others' requirements. (Often, the entire development cycle begins and ends with me.) In the former role, I often find myself writing requirements so detailed that they begin to resemble pseudo-code because I know that the programmer lacks the business context that would facilitate understanding. Sometimes I start to feel as though I should finish the design and code it myself. If I have to spell out my requirements to the degree of precision that a computer understands, why should I hire a programmer?

My experience is that for every business type who's unwilling to understand the need for precision in requirements, there's a programmer who's unwilling to learn enough about the business to understand its needs. And I, like many other business types in the finance industry where I work, probably appreciate the need for precision as much as any programmer.

While I do agree with the essence of this post--that communication is critical--I think it's important to remember that there's more than one side to this story.

michael you are correct. There is as big a problem on the development side, but I was responding to the poster who appeared to have his act together.

In fact I hold developers more responsible for not holding up their end of the bargain because we are supposed to be more logical thinkers, etc.

I read a recent article that questioned the actual success of eXtreme Programming (XP), but one of its fundamental concepts is that end-users are a core part of the team, constantly interacting with the developers and the application as it is being built.

UML (nor any other documentation/specification scheme) simply can not describe an unbuilt application to the degree that a blueprint can describe an unbuilt building. I believe the biggest barrier to successful software is users unable/unwilling to spend sufficient time with developers through the life of the project (this is of course moot if the developer can't/won't interact with the end-user frequently and in jargon-free language).