Damon seems fired-up about the new DSL tools in Visual Studio 2005. But he asks:

Why limit the use of this tool to visual studio users?  Suppose you work in a business with a fairly well defined domain, such as selling mutual funds for a specific company.  If you could define your domain entities, attributes, connections, rules, etc and then put this tool into the hands of people like, oh, say, business analysts you may have a very powerful code-generation and/or documentation tool that is usable by the people who supposedly know the business best.

I'll tell you why.

When presented with the idea, most people will claim they want a tool that allows a domain expert, rather than a software developer, to create software. Or at least they’ll say they want a tool that lets the domain expert configure or assemble software. After all, who knows the business better than a business person? Give these people a nice DSL tool or BizTalk and let them construct the system.

In my experience, however, I've found this desire is not genuine. It's incredibly difficult to get the business folks to commit to a domain model. I’m not implying that we developers are necessarily any smarter or more analytical, but we’re better equipped – and more interested – in creating a logical domain model of a business than a business person is. If you, the developer, create a domain model, a business expert can probably tell you where the model falls short of reality. But I’ve yet to meet a business person that could synthesize a good domain model. Get five business experts in the room and you’ll get five varying models (of the same business).

More importantly, business folks don’t really want responsibility for the solution. For most developers, our work is an expense to the business and the business will (rightly) try to minimize that expense. A company needs to keep its toilets operating; this is another expense. The company also wants to spend as little money as possible on toilet operation. But, when a toilet breaks, the business folks don’t want an easy-to-use, next-generation set of pipe-wrenches. They want a plumber – someone with valuable expertise in something other than the business’ own core-competency.

Likewise, a company needs to keep its software operating. The moment a business person makes a software change that unexpectedly halts the inflow of revenue, they won’t want a great tool. “They'll want a throat to choke,” as my friend Philippe says.

Despite these comments, I’m a firm believer in modeling tools. I think they are useful and will become increasingly effective. But they won’t turn business analysts into programmers. They will be used by software developers to make ourselves more productive – much like a better pipe wrench could make a plumber more productive. These tools will alter the nature of our work, and businesses will earn a better return on their software development investment. But the role of the software developer won't be going away. Luckily for us, nearly all companies need toilets and software to stay in business.