I think it is just a people problem. Programmers tend to seclude themselves from their customers. Whole IT departments tend to seclude themselves from their users.
When you are looking for underwater welders for the off-shore industry, what is better, teaching a welder to dive or teaching a diver to weld?
(that's a serious question with a real answer).
It is much easier for a programmer to acquire the required domain knowledge than it is (usually) for a domain specialist to learn how to program. But you can only do so if you're prepared to 'dive in'.
I base that on the fact that the core value, the welds, will be higher-quality and that's more important than the diving execution.
The diving might be off, but it shouldn't be that hard to learn well enough to survive and be effective. Of course, I'm neither a diver nor a welder.
Did I win?
Yep. But a drowned welder is also not much ;)
https://www.commercialdivingacademy.com/underwater-welding.d...
That's just one program, but it appears diving is the first thing you learn.
Edit: If you look at it from the context of a normal welder, they have an understanding and control of their environment before they start welding. You don't realize it because you've been understanding your environment since you were born. To do underwater welding, you'd first have to understand how you operate in that work environment, and then they can teach you how to start welding in it.
My experience is that it generally has been managers shielding the programmers rather than the programmers shielding themselves.
I could imagine the right match of domain knowledge and the capability to learn how to develop in a non-tech guy and programming skills and the capability to learn the domain in a tech guy would be rather powerfull combination. And pretty rare one, I guess. At least for me, the actual programming part is... difficult. ;-)
On another point, this applies pretty much things like lean or six sigma, too. Both are quite usefull (or can be, that depends!), but people tend to see them as domain by itself. In practice, and that's only my personal opinion, this comes out short. If you add this to existing expertiece in a certain domain, then it works!
3. Create another EUP paradigm. It's been 34 years since VisiCalc came out, and despite it's success, I don't see a lot of effort to get end-users to program, especially in models, like the spreadsheet, where they don't know that's what they're doing. ;)
If you're interested in that sort of thing, ping me (see profile). My company does R&D in this space.
Now we should face three cases: 1) the programmer needs to learn the domain; 2) the domain expert needs to know how to develop; 3) something in between.
Most of developing is done in 1). There are some brilliant cases of 2). I once talked with a biologist doing some multi sequence alignment that told me that some routine in C was quite slow and was far better rewrite that routine from scratch in assembly. I was quite speechless.
In order to create better programming languages we could: 1) express domains in a better way. Actually, just be able to express domains would be really cool (and not so easy). 2) provide higher levels of abstraction.