+972 52-548-6969
Throwing a DSL over the wall
Here are a few thoughts about the idea that given a DSL, you can just turn your entire business related stuff to the business users, and be done with it. This kind of thinking is very common, from the dreams of the secretary building applicaitons by dragging boxes to the business analyst modifying the workflows.
I disagree with this quite strongly. Giving a user this type of tool is an irresponsible step at best. The users are not developers, and they will make mistakes. And the first time that the business will lose money over it, it will be your fault.
- It will be your fault when the server is on 100% CPU because the user has created endless loop.
- It will be your fault when the server is down because of stack overflow.
- It will be your fault that Mike from accounting made "just a tiny modification" that suddenly means that you sold a product with for 50% less than you paid for it.
- It will be you fault that Joe just got a paycheck proudly stating -43.9.
- It will be your fault that the company baught the entire fish market for the next three years.
- It will be your fault that no one has any idea what the company's own business processes are.
- It will be your fault that the database contains incosistent data.
- It will be your fault that there is not control over it.
- It will be your fault that there hasn't been an audit log for the last three months.
It will be your fault
Handing a user a tool like that is wonderful, it is a tool that can enable better communication and rapid response betweenthe IT and the business. Having a DSL means that you are talking in the same language, that you are less likely to mess up because of translation problems.
It does not mean that you can just throw it over the wall and walk away. A DSL is code, and like all code, it requires code review, QA, change management (source control), testing, intention revealing semantics, perf testing, auditing, error handling, transaction handling and much more.
Professional developers are having problems with handling that, giving it to unexperienced users is a mistake. It might work for the first few, but this is not a sustainable approach.
Consider the departmental application and their usual bar of quality. Do you truly intend to bring that, knowingly, into your codebase?
Comments
This is why DSLs are cool but have never been widely successful. Note that I didn't say "widely popular", as DSLs are most definitely popular in the eyes of their steadfast pundits, but at the end of the day the truth for me is this:
If I'm going to be the person held accountable when the application screws up, I want to bring every possible tool to bear both when initially creating the application as well as when troubleshooting it and fixing it later. As such, external DSLs go out the window and development is done in an language like C# using an IDE like Visual Studio, with plugins like ReSharper, a compiler checking everything, unit tests checking everything the compiler checked, automated integration tests checking everything the unit tests couldn't check, and so on and so forth. Most internal DSLs go out the window too, as they are not supported by the fundamental tooling. (for example, Boo is cool, but there's no BooSharper ;)
What is most interesting is in Stuart's comment to your previous post he (perhaps unwittingly) added the first request that can start to bring down the house of cards.
For me at least (everyone obviously has their own personal threshold on this issue), DSLs just don't have enough tooling around them for when the shit hits the fan.
I posted similar recently, it was part of an analysis I did for a client . They believed (because a vendor told them) that they would be able to get rid of all their developers and just have business people writing all their workflows ...
This was for a mission critical system (in that when it failed, people would die) ... they went with the vendor's promises ...
"They believed (because a vendor told them) that they would be able to get rid of all their developers and just have business people writing all their workflows ..."
This is so recognizable. This is exactly what my customer asked me.
The question we are facing right now is, what do we do with it. I'm seeing two options:
1) Let them go for the vendor -- the price will probably be sky high and still want to see whether everything they promis really works...
2) Go for a less flexible system and let real developers adapt it when necessary...
I would go for the second one, but how do you convince your customer that this will be the best solution...
You tell them there is no miracle pill that removes the requirement for skilled developers ...
http://blog.goinsane.co.uk/2007/10/20/AnAnalysisOfTheProblemsInvolvedInExpectingMostOfYourDevelopersToBeMorts.aspx
Perhaps something there will give you an argument you can use ... didn't work for me... too many vested interests.
My shop sells DB querying, reporting, and transaction processing software. The queries one can create are of intermediate complexity: grouping, sorting, aggregating, filtering. The average user cannot [knowingly] utilize all of this functionality to get answers to his questions. We configure most of the queries ourselves and the most the client does is plug in an ID where we tell them to. I know of only a few customers who really use the full power of our software -- the rest just used canned queries & reports.
I suspect the problem is with competency and ability to think precisely -- probably to think like a programmer. One has to understand the different types relationships between tables. One has to understand weighted averages and how you cannot just average a set of already-weighted averages. Understanding normalization is probably also important.
Without competent people capable of the above, I do not see how one can hand the client any tool of significant power, be it our software or a DSL.
Oh snooze. For us old geezers this is like living Texas Instruments "all-in-one" CASE tool that was suppossed to put us programmers out of business - heck I cant even remember how many years ago.
Anyone out there old enough to remember those days besides me? How about the whatever the project name for the Texas Instruments CASE tool? Heck do those guys even do software anymore?
Signed - Mr. Simple
Based on the comments here...
Are DSL really only good as a business rule simulators?
More akin to a test pilot in a simulator.
Test Pilot in Simulator: "Let's see what happens if I shut the engines off in mid flight and stall this thing"
Developer: "Did I put in that physics calc for the absence of thrust? hmm."
Test Pilot in Simulator: "What do ya know it glided down perfectly, I will have to try that tomorrow on the real thing."
No, absolutely not.
They are useful for a large number of usages.
Simplifying what you need to do, clarify, communication - just for the business side.
From the technical side, you get extensibility and expressibility. Consider NAnt vs. Rake.
My point is that you shouldn't assume that you can just create a DSL and throw it at the business user - it is now their problem
I think we are approaching this at right angles.
I agree with you completely but my argument goes back to support your case of throwing the DSL over the fence to the end user.
You don't want the end user to simply manipulate the DSL in production. You want them to work through it with the development team in a test region so that the development team can validate the total effects of business changes.
Not simply trust that since it works in the test region lets move this to production.
Maybe my analogy didn't convey that to well...I apologize.
Joe, yes,
perfect!
Just to point out, plenty of people never even try it in dev. They just modify the "business rules" or "workflow" engine directly in production.
I would say that hilarity enthused, but it wasn't funny.
@Joe - at that point the business users are doing what we do (dev, SE, program)...so that means they need training, degrees, etc...."Oh, look we don't need programmers anymore, the end-users can do it with X panacea tool." In reality this seldom works...
@Ayende - I like your blog you have an interesting perspective on things; Its entertaining to say the least!
If you like ... the issue is that with most 'business user' tools - there is no kind of testing or test framework to prove that what they have done works.
There is no substitute for talented developers ... whether you call them developers, business analysts, architects, rules engine specialists, or 'Dave' - they still have to be damn smart people.
And yes I was around when 4GLs were gonna replace all developers - and I used that argument to my client at the last place ... they knew why 4GLs failed, and their software didn;t have any of those problems ... it also still isn't working 3 months after it was meant to be gong live ... but they got paid up front, and their consultants get paid by the day to work on it ... no surprise there then :)
Comment preview