Matt Terski's Blog

Business Analysts and DSL Tools

Sat, 11 Jun 2005 04:17:08 GMT

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.

Quotations on Software Design

Fri, 13 May 2005 03:16:08 GMT

[Grady Booch] ... Glen Vandergurg's collection of quotations on software design make for fun reading.

I've seen many of these before. A few that I haven't are hilarious.

To a database person, every nail looks like a thumb. Or something like that.

- Jamie Zawinski

The Irony of Outsourcing

Wed, 10 Dec 2003 04:57:47 GMT

I’ve been trading my engineering skills for money since I graduated from college. Last week, I talked to some undergraduates who are looking to do the same.

It was a panel discussion at the Milwaukee School of Engineering. Members of an Industry Advisory Committee fielded questions from students in the software engineering program. The general idea was, we panel members would provide our sage advice to students about to enter the industry. I expected to be asked what a software engineer actually did all day, what tools and languages were important to know, etc.

The first student, wasting no time, asked, “How many of your companies are outsourcing software jobs to other countries?”

Our collective response: Silence. Each panelist waited for another to answer.

After a few seconds a fellow panelist finally spoke up and we began taking turns answering the question and giving our varied opinions on the subject. Most of us said our companies were either outsourcing abroad already or had plans to do so in the near future.

It shows what is front and center in the minds of these future graduates. It can’t be comforting to think that the education you’re working hard to acquire might not get you a job. It’s a topic I think about, too. But it’s not something I’m worried about.

Kevin Laws has written excellent piece that explains why: The Irony of Outsourcing. According to Kevin, the irony is:

Every engineer knows a company that is outsourcing engineering work to India or China, and many are wondering if their jobs are next. Engineers in Silicon Valley are now waking up to the same angst that their technologies have caused in workers elsewhere. Silicon Valley, welcome to America.

But it’s not all bad news. Rather it’s the result of increasing productivity. And in the long run, it’s better for everybody. To find out why, read Kevin’s article.