Reading Sarah George's article [1] on Software Professionalism and the associated comments got me thinking. Which, I suppose, is the very point of the articles on this site. So good show, Sarah.

At first, I thought I could express it all in this comment on the article [2] which I made in response to a comment from Mario Van Damme [3]. But I realized after I posted it that I had more to say on the topic. This whole issue hits home for me because I have lost out on at least 4-5 job opportunities due to the prospective employer's determination that I was short on business domain knowledge. Now, I'm well over missing out on job opportunities from years past, so it's not a personal thing. It's definitely a professional thing. As I mentioned in the comment linked above, there's something here that just does not compute (pardon the pun).

The literature of the field, the formal education available, my own experiences and those shared with my colleagues and peers -- it all points to this line of thinking being totally invalid and actually contrary to the reality of software development as a profession. It's not only incorrect, but potentially harmful.
Here are some points of evidence:

• Contractors and consultants make their careers out of being able to ply their trade in any given problem space. They are usually hired specifically for their expertise as developers/designers -- almost NEVER as subject matter experts (although I will acknowledge niche positions at the intersections). Typically, they are highly paid and regarded as software experts.
• The developers acknowledged as "best of breed"--how are they distinguishable? By being COMPLETELY disconnected from ANY given problem space other than software development itself. They write books, give talks, and submit magazine articles about software development independent from any particular field. This means that, intentionally or otherwise, we as a profession honor those who reach the highest degree of abstraction in their thinking
• Conversely, think of the worst system you've ever worked in or on. Who was it designed by (if there was a "design" at all)? Who was it built by? For me, and likely for many out there reading this, it was a "prototype-cum-production system" designed and built by subject matter experts, or hatched out of an Excel or Access application created by same. Subject matter expertise does NOT make you the ideal candidate to build a software solution in a given problem space.

The key here is that there is both a separation of concerns and a marriage of two kinds of expertise. Developers are experts at building software, creating solutions that in and of themselves are stable, robust and account for big-picture concerns at the IT infrastructure level. They know the technology and the architectural techniques for creating the software. Subject matter experts--be they accountants, medical office managers, salespeople, retail clerks, what have you--are the vital and critical other half of the equation. They know the specific rules that the developer must encode into the solution to make it applicable to the problem.

Does a pharmaceutical rep know the exact molecular biology involved in the actions of the drug they peddle? No. A chemical engineer and/or a molecular biologist and perhaps a team of physicians worked on that end. The rep sells it. They know enough to speak intelligently, and they know the limits of their subject area knowledge, and they know mostly about sales techniques. Done.

Why do lawyers retain expert witnesses? Why does a general practitioner refer you to a specialist? Do you see a pattern here?

The bullet point in Sarah's column [4] about "Minimizing Risks" is where this connects. Something she implies there, even if it isn't stated outright, is that the professional developer is, in general, responsible for abstracting the solution away from the problem. This is how risk is minimized; the design of the solution should provide flexibility along the lines of business logic, such that requirements changes are not catastrophic -- even late ones. The structure of the solution, at the code level, should be implemented such that testing, deployment, and ongoing maintenance are not disasters waiting to happen.

What the developer is not, and should not be, responsible for is knowing the ins and outs of the problem space going into the project.

As I mentioned in my comment to Sarah's article, there needs to be an organic absorption or osmosis of problem space/domain knowledge that the developer undergoes during the lifetime of the project. Active resistance to that process is problematic. But to disqualify a developer from a project/job due to lack of previous experience with a given problem domain... That actually undercuts the entire profession with a logical move completely counter to the purpose of hiring the developer in the first place.

Rant ends. Good day!