Why Is Domain Knowledge Not Valued

Many find it peculiar that DomainKnowledge - knowledge of a specific - domain (business) is not valued to employers nearly as much as technical skills (programming languages, OS's, database platforms, etc.) Companies often dump very experienced company people in favor of an expert in some new language or fad. For example, they may dump long-time COBOL'ers who know the company up and down in favor of web developers. What are reasons for this? [Note: This has nothing to do with domain names, "domains" in the Windows networking architecture, or various mathematical uses of the word "domain"]

BuzzwordCompliant? Um, in the sense that some HR departments will reject an applicant familiar with MS Office because "he doesn't know anything about MS Word".

Laziness - It is easier to test someone's familiarity with a particular technology than it is to assess how much their business or domain knowledge is worth. There are lots of ready-made tests out there for specific things (C++, Java, VB, DotNet, Corba, ...). By contrast, a superior set of abstractions arising from better business knowledge may end up finishing work far quicker, or changing the nature of the project altogether. But that's not something you can score out of 100 on a test. SovietShoeFactoryPrinciple.

Stigma - Often companies view people who have been engaged in maintaining legacy projects as somehow incapable of learning new technologies. Some seasoned developers, however, do put off new technologies, despite the advantages, until after they've been replaced. Sad and confusing, but sometimes true. It's often politically easier to get new people in for a new project than to break up existing teams, which can pick up inertia all of their own. Perhaps management is afraid the old guys know more than they do, and would keep pointing out flaws in a project. Many managers plan to move on before show time, and thus are not scared of project failure.

DomainKnowledge is too specific - In some cases, the knowledge required is specific to an organization or company - and thus almost impossible to get from the outside. In the context of hiring, domain knowledge is deemed to be an irrelevant factor, by virtue of the likelihood that no candidate will have the necessary domain knowledge on his first day on the job. Thus, other factors such as programming skill are considered instead. Of course, that doesn't necessarily explain why established employees with domain knowledge get downsized at the same rate as their peers (or more rapidly, if other factors - such as higher salaries or about to retire and cash out a large pension - make them more attractive targets for layoff).

How would this devalue such knowledge?
It may not be a matter of value, but of convenience. They figure that matching the domain and the development tools in a single person is so unlikely that it's best to focus on filtering by development tools.

Difficult to ascertain - There are numerous certifications, tests, degrees, etc. which can be used to ascertain (to some approximation) skill in something which is domain-independent (i.e. skill in a particular language, a ComputerScience degree, etc.) Testing for domain experts is much harder. [EditHint: merge with "laziness" bullet above or refactor.]

Devaluation of DomainKnowledge in management training - This one is starting to change, fortunately. For quite a while, management schools and MBA programs liked to push the belief that technical skills (management, programming, etc.) were all that's required - and that a good manager (for example) could equally well manage an startup company, a McDonalds franchise, a department within a Fortune 500, a construction crew, or a government agency. Any necessary DomainKnowledge could be acquired on-the-job; or else the manager could rely on subordinates to supply her with DomainKnowledge whenever an issue requiring it came up. This is folly, of course. While many of the management tasks are the same within all examples (basics on personnel management, budget management, etc), DomainKnowledge is necessary for so many of the day-to-day tasks facing a manager. It is quite likely that this belief has been extrapolated to other fields, such as programming.

Quest for a desirable TruckNumber, and interchangeability - Dependence on key personnel with DomainKnowledge (or processes which require DomainKnowledge) adversely affects the TruckNumber of a department/project. By devaluing DomainKnowledge, and implementing policies and processes which de-emphasize it, it is believed that greater interchangeability among personnel can be achieved.

Or is it just that DevelopersHaveNoDomainKnowledge. Or, perhaps candidates don't emphasize it on their resume and interview, and thus reinforce the perception that techies only care about tech.

Also belief that the most important aspects of the knowledge are now available as software. As a programmer you are constantly in the position of DealingYourselfOutOfTheGame? since if the program works well, why are you needed once it is done? If you also have additional specialized knowledge which the software captures, you are doubly vulnerable. The temptation is to find ways to put "hooks" in that only you know and control, but I suspect that is an AntiPattern. One of the seeming ContradictionInTaoism (or was that ZaZen?) is "don't be attached".

Management already has the DomainKnowledge. DomainKnowledge held by the implementers is redundant.

Sometimes, but the opposite is true often. Maybe more often, depending on the domain.
I think they meant it was a belief, perhaps due to arrogance, not an absolute truism.

KnowledgeManagement Systems will keep DomainKnowledge. Once populated and institutionalized, you may not need (engineering) managers either.

Hmm? Hype from the 1980s reappears?
- 1990's version: "Your existing knowledge is not valuable. The game changed."
- 2000's version: "Offshore your knowledge"

Customers have domain knowledge; we can ask them.

For situations with OnsiteCustomer, this seems especially tempting. If you're implementing an accounting system for the enterprise, the staff accountants ought to know how it works (according to this theory). In organizations that develop products for external sale, marketing is frequently chartered with being the repository of domain knowledge, often under the theory that a) they are closer to customers and b) are familiar with various market-research techniques. The problem with both scenarios is that someone needs to transfer design information from the customer domain (UserStories, requirements) into the software domain (code, design documents, UselessModellingLanguage?), etc. Programmers lacking in domain knowledge have a difficult time performing this transfer correctly.

Some think there may be a problem with scalability of developer maintained domain knowledge. Somebody has to have the domain knowledge. Why is it more problematic to leave it with programmers than some other kind of worker? Consider this scenario: you start with a small shop and develop domain knowledge and become very productive. Because of your success a tremendous amount of new business comes your way. As you grow rapidly your domain knowledge is diluted and/or lost. Is it because the programmer churn is high? Maybe because you are not paying them enough or mistreating them. You need more and more Java/Oracle/Net programmers and have no time to train domain knowledge. Next thing you know productivity falls to a level below even when you were a small shop. You business either stagnates or falls apart. If you have seen this situation as a manager then you might think that it is dangerous to build a business model on developers with domain knowledge. See WhyMyCompanyFailed.

I'm not so sure it is a problem of value as it is of cost and control. It is obviously easier to displace the "old-timers" with lower cost, malleable and willing cadre which is more receptive to the inevitable change forces which displaces old technologies and techniques with more modern approaches. It is often true that they are also more easily formed to "follow" the lead of a regime which is interested in conformance which they see as necessary for efficient performance. However if they do not find a way to carry forward the business knowledge in addition to employing modern techniques, they will collapse and/or be absorbed by the more efficient, and success oriented organizations. As to the fate of the "Cobolers" who have not seen the handwriting on the wall since the 1970's and 1980's, and who have failed to update and improve their skills and proficiencies, their cries will fall on deaf ears, since survival in whatever field, is survival of the fittest. -- MarkRogers

Most of my employers have valued domain knowledge enough to pay for my training. My current job uses domain knowledge (check processing) I acquired at a previous job. Some of my employers didn't value domain knowledge, but it wasn't because they were foolish. Either the work they needed done didn't depend on deep understanding of the business or they were willing to pay to train people who already had the technical knowledge. -- EricHodges

The last sentence shows that they value technical knowledge more than domain knowledge. In there mind it is easier to add domain knowledge to a techie than the other way around.

I wonder which is costlier - teaching a domain expert the required tech skills, or teaching a techie the required domain skills? Is age based discrimination an issue here also?

It appears the vast majority of companies would say tech skills. This is understandable to some extent. However, a better question IMO is whether it is considered costlier to train a techie with related domain knowledge a specific language/tool, or an existing language/tool expert the domain.

[Not that I know for sure... but I imagine the tech can learn domain skills far easier than the domain expert could learn tech skills. Techies are by their very nature some of the smartest people around, maybe that's why domain knowledge isn't valued. Maybe knowledge isn't as valuable as the ability to absorb knowledge, which is usually a skill techies have in abundance. That's my two cents anyway.]

On multiple contracts they sent me to "domain school", only to dump many of us contractors at the end of the project and start over with the next batch when there was a need for developers again. Hardly OnceAndOnlyOnce.

I think in general managers do not respect domain knowledge. There is the saying "a good manager can manage anything" implying it doesn't matter what you know about the domain, it will all work out. My response to this is that there are very few good managers, most managers are mediocre at best and some are outright dangerous.

Some people viewed that it is because DevelopersHaveNoDomainKnowledge

Well, when I do gain some, the companies don't seem to care. They send me to costly training, etc., but still do the usual pump-and-dump JIT-developer cycle dance. True, it does not make me a domain expert, but they don't seem to give much value to the bit I do gain. A new person that comes in when they later decide to ramp projects back up is going to have to go through all the same orientation, ask the same questions, make the same domain-newbie mistakes, etc. That cannot be efficient.

It's good to value a programmer's DomainKnowledge if it makes that programmer more productive. More obviously put, it's good to value productive workers, and one would expect that in practice this tends to favor programmers with DomainKnowledge. However, there are bad reasons for valuing DomainKnowledge. It is bad to value DomainKnowledge in the belief that:

Retaining domain experts will decrease the amount of research or customer interaction that needs to be done in the future.
Having a few extremely competent domain experts means that the other developers can get all their information in-house.
Having domain experts with decades of experience will help your company stay on top of the domain industry's evolving software needs.
DomainKnowledge is a valuable asset, and failing to use it in some way is always wasteful.

These reasons can be treated one by one. (The last one, despite being the most common and powerful in people's minds, is a pretty mundane fallacy when you think about it.) However, rather than contemplating the logic of these reasons, consider the big-picture consequences of trying to use DomainKnowledge in these ways.

When domain knowledge is treated as an asset that must be utilized, new developers are forced to rely on more experienced developers for understanding. New hires remain unproductive and dependent on the old guard for too long. By the time your new software engineering grad with his exciting ideas becomes productive enough to assume significant responsibilities, he's more comfortable with C macros and debuggers than with UML and limits all his public symbols to five characters in case some old fart wants to link his libraries.
- Your example assumes UML is a good thing. Some of us dispute that. But if a long-timer does not update his/her knowledge, then perhaps that problem should be addressed by encouragement rather than replacing them with a new dog. Old technologies are not necessarily so bad that abandoning long-earned domain knowledge is worth it to bring in "fresh blood" for technology alone. For example, there is no evidence that new languages make one significantly more productive than COBOL. Aged COBOLers probably know their way around COBOL so well that even with its flaws they are productive.
When the most experienced developers are treated as authorities, new realities get implemented as variations on old realities. Consider a program whose default behavior is a perfect system for ten years ago and which implements anything newer than ten years old as a special case. History hasn't just left its mark on the program, it has left its mark on the mind of the implementer. As with software, some people regularly and instinctively refactor their understanding of the domain, and some people don't.
When the encouraged practice is to refer to in-house domain experts, those domain experts become the target system for company developers, regardless of how current their knowledge is. Employee behavior will reflect the political cost of seeming unable to operate within company practice.
When all software development has dependencies on senior gurus, little new software gets written. Every time a new piece of functionality is needed, it's faster for the keeper of a million-line legacy app to add a few gotos than to communicate the required domain knowledge to a less experienced developer. Again, newer developers remain helpless, and assimilation into old ways becomes the only path to effectiveness and career success. (Not to mention that you end up stuck with monolithic, bloated, crufty code, instead well-factored software.) {What is MonolithicDesign?}
The best software developers don't want to work with your company, because any efforts to use modern tools or techniques will be overridden by the need to work productively with your domain gurus.

The simplest way to sum up this problem is that when a company relies on certain domain guru developers for domain knowledge, the irresistible tendency is for those developers to control design, architecture, and technology strategy. In other words, the developers with the least interest and expertise in software set the software standards for the entire company.

The answer is to adopt the attitude that domain knowledge must be constantly freshened by new research. Letting a fresh set of eyes start from scratch on a problem should be seen as an opportunity for innovation and competitive advantage, not a wasteful squandering of the old guard's experience. Indeed, it should be considered a necessary part of a company's intellectual hygiene. As an asset, DomainKnowledge should be maintained the same way a codebase is maintained. A codebase must be constantly reevaluated and refactored, and occasionally partly rewritten, to stay relevant and usable. Retiring portions of code is often necessary for the health of the codebase, and "losing" domain experts, or at least not clinging too tightly to their experience, may be necessary for the maintenance of a company's DomainKnowledge.

To carry the analogy with software a bit farther, a virgin employee can outperform an employee who has had too much much exposure to a domain, just like a brand-new application - unsophisticated, inefficiently coded, and suffering from high-level language overhead - can outperform an old hand-tuned application that performs data encoding conversions at every interface, spends half its time considering whether to perform functions that haven't been useful in ten years, and has a curious "optimization" developed to accommodate the usage pattern of your second-best customer.

On the other hand, when the new dog optimizes away the optimization and you lose your second best customer, maybe you will value that domain knowledge. There seems to be a false dichotomy here between domain knowledge and "bleeding edge" technology. First, not all "bleeding edge" is going to prove beneficial. We have all seen flash in the pan ideas (Power Builder, anyone?) that got a lot of attention and resources and then died. Second, just because you retain information, or (gasp!) are old, does not mean you are not open to new technologies. This is a bit of an absurd contrast people are emphasizing. Of course, managers may see it that way. But that is also why many tech companies tank rather quickly. Age, experience, even a wealth of domain knowledge does not equate to being hidebound or closed to new technology. (eg. While I still prefer C for anything requiring speed or low level processes -- when they won't let me use assembly -- I have studied Java, Python, and others, and regularly use whatever language is required, and for higher level functions tend to pick the language best optimized for the task . I continue to check what new ideas are coming, but, unlike the "new dogs", I have seen enough "new best things" to know not to buy into the hype. Which may actually be more efficient than the boundless enthusiasm for anything "new" that I am seeing in some comments.)

CategoryEmployment, CategoryBusinessDomain