The lack of this kind of domain knowledge - either from being unwilling to go find it, or not being given the time and the resources to do so - is a big problem for tools development in games. People doing the scheduling and planning tend to assume that if you put enough smart programmers in a room and give them detailed specifications, they'll be able to solve all the problems faced by some artists and writers in another room, even though they don't know anything about art or writing. Sometimes this results in the kind of obvious mistakes that you might otherwise assume only happen when you're writing software for the government.

In a sense it's kind of sad: In building traditional software, understanding the customer is one of the hardest steps because you can't simply walk over and observe them going about their daily work, or ask them questions on a regular basis to understand their issues - you're separated from them by a sales process and probably some automated support tickets and a PR guy who won't let you have open discussion in public. People building tools for game development can have their customers sitting a few desks away!