Whenever there is a broader family gathering of any kind inevitably my uncles and aunts get to the question - what is it exactly that I do? They know it has something to do with computers and they've heard about the term software but it's still hard for them to really understand.

My initial impulse is to try to explain but then I give up and just say "I make programs" (they like programs much more than, say, applications). It would take way too much time to do the topic justice. On the other hand, I do have this place for such things, so here we go...

I see software developers firmly split into two camps - those who learned the problem domain they are solving and those that didn't. Some also like to use terms like vertical software and horizontal software respectively. Why is it so? Well, there are only so many things one can learn. Software helps solve many problems and it is unreasonable to expect from the developer to know them all - finances, plumbing, building construction, accounting, travel agency schedules, microbiology etc. Thus some of us (me included) opt to stay highly technical and apply their knowledge to the wider spectrum of problem domains.

How do we do it then? After all, you can't really solve a problem unless it is something either trivial (in which case someone has probably solved it already) or if you deeply understand it. The answer is domain experts. People who know the problem well but couldn't code if their lives depended on it. We need them and they need us - together we can solve almost any problem worth solving.

Ergo, software developer is the one that translates the knowledge of domain expert into the applications(s) that solve particular problem. Many underestimate the effort this takes. Many just want to code (these are usually categorized as programmers) and be left alone. But it is clear from the definition above that (assuming that both developer and domain expert are good at what they do) the biggest problem in software development is communication channel between the developer and the domain expert.

But don't take my word for it - let me give you one of the greatest quotes recently from the most excellent article on Language Workbenches from Martin Fowler:

This promise of bringing domain experts more directly into the development effort is perhaps the most tantalizing part of the language workbench promise. Time and time again we see that whatever tools we programmers use to boost our productivity there's a sense that we are optimizing the idle loop. On most projects I visit the biggest issue is the communication between the developers and the business. If that's working well, then you can make progress even with second rate technology. If that relationship is broken, than even Smalltalk won't save you.

The article (quite a lengthy read but absolutely worth it) tackles the problem of better domain experts involvement through the development of DSLs, domain specific languages. There are supposed to be simple languages more expressive in the domain problem so much so that even domain experts can use them. The author is skeptical (and I agree) that this will be possible in the near future, but even if domain experts can read DSL based code we have all made a giant step forward.