Strumenta Reduced Feedback cycles
Domain experts and developers do not understand each other.
The feedback cycle is way too long and when developers present a result to your domain experts they shake their head: this is not what they expected.
By using a DSL domain experts and developers can collaborate: feedback cycles are reduced dramatically and you can ship in weeks what used to take months.
Shorter time-to-market
You are developing a specific kind of applications but each time is almost like restarting from scratch.
Your time to market is way too high.
With a well-crafted DSL you can reduce development time by 10-20 times. You will be able to react very quickly to the demand, evolving your product or service at a pace which is unimaginable with traditional development methods.
Incidentally, also your costs would reduce accordingly.
Increased productivity
Consider the cost of your personnel. How much would be worth to get the 10% more from them? What will happen if instead they became 10 times more productive?
Research and my personal experience show that 20x in productivity is possible, in some cases
More productivity means different things. It means lower costs, but it also mean less time spent to recruiting personnel, it means smaller teams and less communication costs.
Example
For confidentiality reasons we cannot share the exact DSLs we have built for actual clients.
However we can share an example of DSLs that could be built, fairly close to what we have built for actual clients.
A DSL for marketing automation
There is a company selling a large range of different products through an e-commerce website.
They employ a few tens of developers and system administrators and around ten marketers.
Before
(without the DSL)
Marketers spend a fair amount of time studying the data and coming up with new promotion. One thing they have learned is that targeted promotion is the key: each kind of customer respond to different kinds of offers. Some of them just want discounts, others value free-shipping a lot. So Marketers devise more and more of these promotions and each time they have to run to developers to ask them to implement those.
Developers are really bored by having to implement all these small promotions for marketers. They are always coming up with new ones. Getting them right is a bit tedious and from time to time they make a mistake, causing issues to the whole ecommerce website, which is a big deal for the company. Another problem is the fact that marketers do not express perfectly well what they need to there is some back and forth for each single promotion. From time to time there are also problems because marketers are not good at envisioning the possibile consequences of a promotion, the fact they could affect more people than intended or that they could overlap with other promotions. These things come up when the promotions are live and at that time is too late to cancel them.
After
(with the DSL)
Marketers can now define the promotions using a simple DSL. It permits much more configurability than a simple wizard or a configuration panel. As they need to define more specialized promotions the DSL is becoming more and more useful. Marketers are now independent: they can define their owne rules without begging developers for help. The system permits also to run simulation and that means marketers can see what is going to happen: who is going to receive the promotion, with which other promotions it overlaps. Now they spend more time looking into data and thinking about campaigns and less time bothering developers.
Developers can now focus on more interesting tasks. At the beginning they helped marketers learn the DSL but now that marketers are independent developers can focus on improving the platform, improving performance and the rest of programming tasks they like so much more than writing another promotion for diapers targeted at mothers between 20 and 30 years old living in Idaho.
Technologies we use
We believe addressing the right problems and designing the right solution matters more than the technology we use.
However one size does not fit all: depending on the goal of the project that are some technologies that would work better, because of this we work with different approaches in different cases.
Jetbrains MPS
Jetbrains MPS is a projectional language workbench which permits to do incredible things.
You can use textual, graphical, and tabular languages together, to create an extremely rich solution for your needs.
It is a revolutionary approach, with a growing adoption. Definitely something you should look into.
Xtext
Xtext is a dependable and mature solution to create textual DSLs. It is part of the Eclipse Modeling Framework and that means it can be integrated with other components to create rich DSLs and modeling solutions.
Custom solutions
Sometimes you cannot use an existing Language Workbench because they come with their own constraints. In that case we can develop lightweight solutions that integrate with your existing tools. We typically start by writing parsers using ANTLR in that case.