The other issue with domain knowledge, at least in my experience, is that it takes a significant effort to become sufficiently knowledgeable in a new domain to discover and solve the real problems faced by people working in that domain.
Why do you perceive statement #1 to be factual?
If you have no domain expertise, you have no way to evaluate it. _DPS's example sounds -identical- to someone without domain knowledge, and yet is comically absurd.
I agree with the article, domain knowledge is important and under-appreciated. It's strange that companies hire SW engineers mostly on knowledge of the tools rather than understanding the problem domain. It's a wrong Taylorist idea that programmers should focus on how and not on why.
> How much domain experience is necessary to solve the problems you have. isn't that something you learn/pick up once you start solving em?
If you are a domain expert when you start, then the problems you have are more likely to be real, significant problems in the domain, and your attempted solutions are more likely to be both novel and well-considered in terms of the problem than is the case for someone with less domain expertise at the outset.
> Sometimes this results in the kind of obvious mistakes that you might otherwise assume only happen when you're writing software for the government.
My personal guess is that the reason there too is lack of domain knowledge. That many government projects are ran by handing out specs to the people tasked with implementing them.
Sometimes it is. Sometimes it isn't. I figured that out after spending some time writing software for a highly domain-heavy software company - think half the employees are physics or chemistry PhDs, top brass is old-school classical engineering but also familiar with modern software methodologies.
Since I was building components primarily doing data exchange or other generic software work, unrelated to the domains the company was targeting, I thought I could get away with minimum, surface-level domain knowledge. And technically, this was true - my work never really required understanding any of the complex non-software stuff the PhDs were discussing. But on a more fuzzy, emotional level, it was a different story. Being unable to understand the point of half of the conversations I hear, or even keep track of the acronyms and terminology used, was very draining and demoralizing. And sometimes it would, indeed, make me guess badly about which parts of my work were most important, as I didn't fully know the path connecting my purely software work in the bowels of our product, to the value the software generated for the customers.
So my advice is, domain knowledge matters even if you're separated from it by half a dozen layers of abstraction and only doing pure computer stuff.
I'd argue the opposite. Too much domain knowledge leads to creation of the very same "solutions" that have existed with minor tweaks. See Henry Ford faster horse for reference.
I should point out that by "domain knowledge" I meant the domain of a particular language and/or platform. For example, having a deep understanding of what is available in .Net in C#, or STL + Boost in C++, or CPAN in Perl.
Real-world domain knowledge is somewhere between helpful and vital, depending on one's role.
Completely disregards this little thing called "domain knowledge". Maybe no-one cares if you're just building websites, but in serious software, knowing about the problem your application solves in the real world does matter, and does get more valuable over time.
Very true. There’s a huge difference developing in a well known vs. new domain. My mantra is that you have to first be experienced in a domain to be able to craft a good solution.
Right now I am pouring most of my time in a fairly new domain, just to get an experience. I sit next to the domain experts (my decision) to quickly accumulate the needed knowledge.
“One of the main insights of the paper is that domain-specific methods are able to yield bigger improvements than more general approaches. This is an important lesson that will have ramifications for other domains.”
While true in the real world this wasn't part of the problem as written above!
reply