On: The Economics of Testing Ugly Code

But testing also reduces ugliness: The act of making code unit testable makes it less ugly, because unit testing requires access to a portion of the code in isolation, thus making the code more modular. Modular code is less ugly (or so I claim).

That's an intriguing idea about DSLs enabling customers to see the ugliness. But why would customers look? (A parallel is non-lawyer customers looking at legal documents for beauty) Does anyone have experience with DSL's for non-developer customers? eg: SQL is a DSL for business analysts - but they develop in it, not just look at it.

This form of testing is called production. :)

Does anyone have experience with DSL's for non-developer customers?

I did that on one project. It didn't work. The response we got was "But I'm not a programmer." We replied, "But you don't understand! This is not a general-purpose programming language, it's a high-level domain-specific scripting language!" The response we got was, "But I'm not a programmer." I learned a lot from that experience.

Yeah... but in my company, there are many cases where job positions have spontaneously materialized that are essentially programming positions, but that we have "con" someone into doing it even though it really is programming. The users are, for all intents and purposes, programmers... but we have to keep them from finding that out!

Surely you're not going to get very good programmers that way?

But they're not technically programmers. I'm talking about applications that require extensive customizations to be useful. There's a lot of cases where people are having to trick people with the business knowledge into doing the configuration for them because the 'real' programmers can't or won't do the work. _This_ is where we should be looking at applying DSL's.