Developers Have No Domain Knowledge

Sooo, in the context of hiring and firing some developers ask, WhyIsDomainKnowledgeNotValued? And various reasons why are suggested. But the big one isn't: developers don't have any domain knowledge (none worth speaking of, anyway). They may have memorised some domain facts, have gained some familiarity with the working of some domain techniques, of course, but that isn't the same.

Would you be happy to hire a programmer who happened to have worked on an accounting package to do your tax return? Would you be happy to consult a programmer who happened to have worked on a medical informatics system about your child's illness? Would you be happy to have a programmer who'd worked on a flight-sim land the airliner you're travelling in?

No, no, and no. But were I to hire a programmer to work on an accounting package/medical system/flight simulator, prior experience working on such systems would certainly be a feather in the cap of any qualified candidate. Not enough to replace raw programming skill (I'd rather hire a GrandMasterProgrammer with no DomainKnowledge than a OneStarProgrammer with extensive knowledge, if it's a task that a senior programmer is needed for), but certainly valuable.

DomainKnowledge doesn't mean being an expert practitioner in the area in question; it does mean having some fundamental knowledge of the area.

Would you vote for someone for mayor because they wrote part of SimCity?

Now, it's arguable that a company that (as is suggested on WhyIsDomainKnowledgeNotValued) drops its experience folks in favour of buzzword-compliant newbies is wrongly assessing the value of something, but is domain knowledge that thing?

Meanwhile, isn't it a frequent symptom of a pathological relationship between the suppliers and purchasers of development effort that the suppliers get to thinking that they understand the purchasers' business better than the purchaser does?

Within the context of the application being developed, existing inhouse developers have the domain knowledge to define the existing application, sometimes better than individual users.

That having said, I can agree with the assertion that the domain knowledge is insufficient to operate the functions within the business unit.

Note even if business processes are being re-engineered, it is useful to have someone with extensive knowledge of the ins and outs of the existing application on the BusinessProcessReengineering (BPR) team.