Everyone Needs Their Own Programming Language

The key to bootstrapping Collage.com to $86m in revenue was keeping a lean team of only 15 engineers. We aggressively automated core business processes like adding new SKUs, vendors, or coupon types so that they took hours of engineering time, while our competitors took months (which we learned by interviewing former employees).

The Path to 100x Engineering Efficiency

How did we reduce tasks from a month of engineering time down to an hour, or even cut out engineering entirely? By creating a programming language specially designed for our business that made common tasks as easy to implement as they were to describe.

In particular, we built a hierarchical content management system where entries could inherit properties from multiple parents. This let us express precise business logic with similar complexity to the human language specification.

For example, to add an existing product for a different vendor, you could just reference the product and vendor definitions, and then override anything unique to that combination – like the cost. The length of the new product/vendor definition was about as long as the Jira ticket description.

Without a business-specific language, our competitors took weeks or months to implement the same features using common programming languages like Javascript.

Our language let the business scale without adding more engineers. In computer science terms, our team size was O(1) relative to our revenue, while our competitors were at O(n).

minware’s Language

We’ve done the same thing at minware and created minQL – our own language for querying development metrics. It abstracts away the hard parts of handling interconnected time series data (e.g., tickets, time logs, and commits) so that “show me the average time from ticket creation to first pull request review” becomes a one-liner.

With minQL, we can create reports in 30 minutes that used to take us (and still take our competitors) weeks of development time. We abolished complicated SQL queries and custom React components, replacing them with much simpler minQL – letting us move faster with fewer engineers than our competitors.

Standard vs. Business-Specific Languages

A well-crafted business language will always win against a standard language like SQL or Typescript when applied to its domain.

Standard programming languages are wonderfully powerful, but that power has a cost for tasks that don’t need it.

Because standard languages are general, you can easily shoot yourself in the foot with issues related to performance, security, and business logic. Standard languages have more failure modes, which at the very least means more extensive testing and review for each task.

With a business-specific programming language, on the other hand, you only have to do this testing and review once at the compiler level, and each individual task is easier to validate within the limited semantics of the language.

The AI Factor

Perhaps the greatest long-term benefit of a business-specific language will be that it is much easier to generate with AI. Nick Schrock made this point well in his recent post about the benefits of “medium code.”

While there is a lot more training data for standard languages, AI makes a lot of mistakes and probably will continue to do so for a while.

Even if AI does get it right in a standard language, the code is more complex than a constrained language and will require more time from an experienced (i.e., costly) engineer to read and validate.

With a super concise business language, the constraints increase the chances of success for AI and drastically reduce the expertise needed to understand and test the output.

Why Creating a Business-Specific Language Is Hard

If business-specific programming languages are so great, then why are they so rare?

Well, they are difficult to get right.

Off the bat, you need a highly skilled computer scientist to design the language and implement a compiler – a notoriously tricky task. At minimum, it's a large development project that requires substantial training and documentation as well.

The real issue though is that this computer scientist must also have deep first-hand knowledge of current and future business requirements.

One way to mess up the language is to make it too generic, which leaves you where you started and misses most of the benefit compared to a standard language.

You can also make it too limited by only handling easy scenarios, or only supporting past use cases while future ones are different. If people have to work around the language or use escape hatches for anything hard, then it won't be very useful.

If the business itself doesn’t have a clear picture of what common development tasks it will do in the future, or the person designing the language isn’t hands-on enough to understand the hard problems developers face that could be solved once and provided as a language abstraction, then the effort will fail.

The Bottom Line

At the end of the day, to build a useful business-specific programming language, you need an empowered architect with clear business guidance who’s not sitting in an ivory tower.

It’s definitely possible, but not likely to happen by accident. The CTO needs to care and make it a priority.

For those who succeed, however, there is tremendous potential to run circles around the competition.