Marketing Virtual Meetup

I think this topic would be very interesting.
However, we already established we’re not good at marketing. Maybe someone here knows a marketing expert (or at least non-noob) who would be willing to join the discussion? I think they would not need to give any actual presentation, just provide a more informed opinion.

2 Likes

Good!

That would be awesome. I would try to spread this message on Twitter and LinkedIN and see if we can find someone.

In the past I spoke about this topic with people with more experience in marketing. What I got from them is that:

  • We should understand who we are selling to
  • We should understand why they buy, when they do
  • Ideally we should have a marketing message focused on a specific industry, or focused on a particular group that people feel they are part of (e.g., small business owners think of themselves as small business owners)

What I can also do is to prepare a few slides with some areas of discussion we could focus on. These are the first that come to mind:

  • Confusion around the term “DSL”
  • Defining the advantages of DSLs
  • Understanding what are the alternatives to DSLs (i.e., what is people buying instead?)
  • Issues preventing people from buying DSLs
2 Likes

I have prepared some ideas to start the discussion:

Promoting DSLs.pdf (168.7 KB)

1 Like

I translated some of the notes from the meeting of yesterday in this series of tweets: https://twitter.com/ftomasse/status/1332030862326718470

2 Likes

From my point of view it was very interesting. I think to get more results we should dive into specific problems.

We discussed the fact that to promote DSLs we need to:

  1. Capture attention
  2. When we have the attention, defend the choice of DSLs w.r.t. to other solutions, winning the resistance on some issues (“it is weird!”, “creating a language is crazy!”, “I will lose my job!”)

I personally considered the first phase the critical one, as most people have no idea DSLs exists. However others suggested the problem is instead convincing those who look into DSLs to win their resistance.

We seemed to agree that who buys DSLs are not developers. However they need to be brought on-board, to not cause internal wars. We are not sure who is target. We named CEOs and CTOs.

The advantages we listed for DSLs seem also to be claimed by other solutions. Perhaps the very different one is “capturing knowledge”.

1 Like

For me, the fact that a DSL can “capture knowledge” is – in a way – less important than the fact that a DSL is the only solution that allows domain experts to build and test their solutions using their own jargon, in a flexible way, without depending on a developer. With a DSL, domain experts can devote themselves full time to create “knowledge captures”, without having to explain to a developer what they want to achieve, and having to wait for the developer to “capture that piece of knowledge”, in an inflexible way, in the source code.

A DSL allows the experts to be independent when making tests, to obtain a faster feedback of the results, which allows him to make corrections in a faster way. This is reminds me of the fact that when two people have to communicate and do not know a common language, they have to use a translator: communication is never as fluid as if both can speak in a common language for both. Using a DSL, communication between the expert and “the solution” can be direct. Without a DSL, a translator (the developer) is necessary for the expert and “the solution” to communicate.

I am reflecting on this, and I thinking that the different ways to build value using DSLs are related to knowledge.

In this sense you underlined the importance of reducing the cost of capturing that knowledge. If experts can do that on their own, without intermediaries (analysts and developers), it means saving time and money.

Other advantages are:

  • Accessing that knowledge, as other experts can read and understand
  • Improving that knowledge, as errors are captured (this is the second point you raised, when talking about tests)
  • Leveraging that knowledge, as some code generator or interpreter will be used to benefit from the DSL in some form of automation
2 Likes

I like the term “Knowledge Centric Development”!

Development speed is an argument for using DSLs, but it’s quite superficial. Knowledge capture using DSLs is much more long-term.

1 Like

Great!

In these days I am reflecting on a whitepaper for this idea behind “Knowledge Centric Development”.

The idea would be to encorage people to reflect on how they work with knowledge. The king technique proposed would be to adopt some DSL, to facilitate how knowledge is built, verified, and accessed (as people can read DSL and learn from it). However it would also include other elements related to extracting knowledge from existing artifacts (code, models, and other sources), to provide tools to work with knowledge (editors, visualizations), and derive value from it (code generators, simulators, documentation generators, interpreters).

It would also touch on processes.

I mean, I realize we always talk of “DSLs” but DSLs are only a piece of the puzzle, and all the solutions we build have something more of the language itself. In a way DSLs are just the thing we need to enable the other tools and the changes in processes we desire. So I am wondering if one could present all of this under a more comprehensive name.

3 Likes