The problem is that “programmers” often don't know much about the
domain their programming within. Of course, they have to come to
understand the domain a little bit to build the program. But too often
that domain knowledge is transferred through software Requirements and
Specifications. My boss, JP, once opined that you can write a big,
thick book of specifications and hand it to a good programmer, and get
a working product at the end. Perhaps you can — if that book
functions to educate the programmer on the domain knowledge of the
program.

In 2004, I gave a talk to Computer Science students at Valdosta State
University about Domain Expertise. I said, back then, that you
shouldn't expect to write a program about a business domain unless you
could also write a book about that business domain.

Just recently, a giant multinational corporation approached my
employer about a software development contract. They know we
understand the domain, but they expect us to outsource to overseas
programmers. I have nothing against anyone who writes code and lives
somewhere else, but it's amazing that this corporation isn't as
interested in the domain knowledge as much as the low pay rates in
other companies.

What you really need are domain experts who also write programs. Like
my friend Aaron Kahn who works with the Naval Research Lab. He's an
Aerospace Engineer — who also writes programs. When he visited last
year, he was interested by my collection of books on programming. He
knows aerospace engineering first and foremost — and writes code to
implement the ideas he knows.

Was there really ever an era of cheap programming? I doubt it. Good
software in complex domains is always the result of good comprehension
of that domain. The best place is for that comprehension to lie with
the developer.

Open Source software development tools are so good because the people
developing the software were, of course, experts in the software they
were developing. They were building tools for their own use. This
really follows the non-selfconscious design process described by
Christopher Alexander. They didn't build software because they had
specifications for it; they build and improve their software because
it has a problem, and they just want to fix the problem.

Professional programming, unfortunately, is often self conscious:
somebody tried to write the Big Book of Specifications while somebody
else tries to build it. And, as Alexander predicts, this kind of
process fails.

So, Practicing Computer Scientists: get expertise beyond computing!
I'm growing expertise in telephony — connecting people for real-time
voice communication. My friend, Chris Vaughan, has expertise in
banking, and in hospital lab management, and some in industrial food
distribution, and probably expertise in other fields.