No-code: the Excel of the modern age

• Organization

Excel, a wonderful tool

Please don’t take this as derogatory or mocking—quite the opposite.

Excel has been with us since 1987, for better or for worse:

• The best part: Excel lets you prototype an idea in just a few hours. Start structuring the information and organizing it into multiple tabs or files (different bounded contexts?). This lets you get moving fast when you’re not sure what you need, to learn, to answer your own questions, and so on. Basically, build a proof of concept (POC), see if it helps, and, over time, figure out whether it’s enough or if you need to build a full-fledged application.

• The worst: the law of the instrument. If the only tool you have is a hammer, you’ll tend to see nothing but nails… even when you’re dealing with a screw. Doing everything in Excel because that’s the only thing you know and you’ve mastered the tool inside and out. So, inevitably, you end up overdoing it: a hefty dose of VBA, which quickly becomes unmaintainable and a source of numerous security vulnerabilities. It turns into development—but development done by people whose job it isn’t. And in the end, it’s the IT department that’s left to clean up the mess after the system crashes (Shadow IT).

What role should low-code/no-code play?

In my view, low-code/no-code tools (Retool, Bubble, SAP Build, and Airtable, to name just the best-known ones) offer the same benefits as good old Excel:

• They promote the autonomy of business teams, and thus innovation;

• They relieve IT of tasks with lower added value: validation workflows, technical administration tasks, back-office functions, or even simple front-office tasks (such as CRUD);

• Ultimately, they let us answer simple requests fast, giving the whole company a shot of agility.

As a developer or CTO, it’s easy to scoff at this and look down on it from a position of superiority. However, we’d be well advised to take a closer look at these tools.

The key is knowing how to provide guidance for this practice: it’s good for the business side to take the lead, but the process needs to be supported along the way.

Go with the flow

Fifteen years ago, I did an internship at a major French energy company, which is now in the process of being nationalized (it’s not at all obvious which one I’m referring to). A team of three or four developers worked alongside the traders to ensure everything was done properly and to prevent things from getting out of hand. We called it Rapid Development (RD), and it worked very well.

Here are a few suggestions:

• Recommending a tool in order to pool expertise and costs across the company (because, let’s face it, it’s not exactly cheap either);

• Promote best practices to limit technical debt (anticipate the day when you’ll turn it into a real application);

• Constantly reevaluating your dependence on the platform, since platforms are free to change the terms of the agreement overnight—or even shut down their operations.

In any case, the use of low-code/no-code makes perfect sense within the framework of a Domain-Driven Design (DDD) approach. The “make or buy” question, which arises in every context, now has a new middle ground.