What it tells me is that preventing the developers from talking directly with the users, a practice which is mind-bogglingly common (bordering on universal), is

What it tells me is that preventing the developers from talking directly with the users, a practice which is mind-bogglingly common (bordering on universal), is a hurdle which companies are incapable of overcoming. There really is no replacement for a developer who can become embedded in the organization which is going to be using the software, watching or performing the job themselves for any position which is going to be enhanced by using the system being built, etc. I have always wanted to do exactly this as a developer, and the closest I have been able to get was on a couple freelance solo projects. As far as I know there's not even really a name for a person that functions this way. The closest I've seen is "Business Analyst", but if you just look for positions with that name you find nothing even remotely close to actually doing that sort of thing. As a developer, it is normal to look at a system and extract the generalities and patterns and systematize them. Then the users start using the system. And they always ask for the same things. Exceptions. The ability to cheat the rules they swore were "always" the case. If they've got someone on the staff who knows just enough to be dangerous, their system will grow by bits and pieces organically, eventually resulting in a real nightmarish mess. For years I have wanted to try to design a system which actually has this in mind as a primary use case. Something which can be bit-by-bit 'expanded' over time with the special cases, exceptions, etc but which can remain sensible, maintainable, and tractable. It's possible that such a system cannot be made both as flexible as necessary and still usable by the average person, but I think it might be. Anything which accomplished the goal even partially would be pretty successful I imagine.