Domain knowledge is highly overrated. If a company requires every developer to know the intimate details of the domain that the software is being developed in, not only is that a waste of time and money, but it is a sign that the software is broken.
There needs to be levels of abstraction in software in order to do anything significant and that requires levels of abstraction in developers. Sure there has to be a few people who are experts in the development domain, but ultimately 10 experts in domain XYZ, who are not experts in software development won’t get you very far. A few experts on the domain plus people who know how to properly develop software is a much better long term strategy for the makeup of a software team. It is even better if your domain experts are expert software developers as well, but the reverse is not true. This team makeup will force you to abstract away the domain issues so that the non-domain experts don’t have to deal with aspects that they don’t want/need to know about. As a non-domain expert who is more interested in the software development than any domain, I embrace ignorance and apathy. I don’t know and I don’t care. Domain knowledge can all be abstracted away so that I don’t have to fret about the details. If I do have to know and care about the details of the domain then the system is broken.
From a company point of view, it is a waste of resources to train everyone on the details of any domain. You just need to train a few people who can write the software to encapsulate domain knowledge and from there on in, you are just pushing data around. You are better off training two or three experts in the domain and many experts in software development. Both camps will know something of the other camp, but can concentrate on what they know best. From a developer point of view, it can be good to become an expert in a particular domain, but if it is at the expense of learning how to make software development work in multiple domains, then your long term viability in the marketplace may be hampered. What happens when the domain goes away or declines? Unless you are one of the top gurus in the area, then you may find your skills that you do have are not needed anymore. You may not have the more general software development skills that are needed in every other domain.
I worked in telephony for two and a half years and I don’t know anything about telephones. Not because I wasn’t allowed to learn or was held back in some way, but because I had better things to do. The telephony was abstracted away and I didn’t have to know or care what was going on at that level. For all I knew, I was interacting with a very very fast human operator rather than a telephone switch. In reality, I did pick up a few bits of telephony knowledge but that was mostly by osmosis. The point is that I didn’t _need_ to be an expert in telephony in order to build large, highly available, fast, telephony applications (see here and here).
In the end, it will be hard to convince a company in the XYZ domain that they don’t need all their developers to have 10 years of experience in XYZ because they are obviously so heavily invested in their particular domain. It is somewhat counterintuitive to think that less knowledge is better, but in this case it is. I for one, don’t have any interest in any domain, and I like it that way. I like software development, not software development in the field of XYZ. And somewhat contrary to popular belief, there are many issues in software development which have nothing to do with the domain in which the software is being built and which can be universally applied to many domains. These issues are not being addressed properly in many software development groups.