"No code" does not equal "no logic"
Everything Starts Out Looking Like A Toy, #82
Join smart, curious folks to get the Data Ops đ newsletter each week (itâs free!)
Hi, Iâm Greg đ! I publish this newsletter on finding data products and interesting data observations with the goal of finding patterns and future product insights. (Also, itâs fun.) If you need a background on how we got here, check out What is Data Operations?
This weekâs toy:Â placing a vintage 100+ year old lens in a mirrorless camera. Edition 82 of this newsletter is here - itâs February 21, 2022.
The Big Idea
A short long-form essay about data things
âď¸ Bringing a programmerâs mindset to no-code

If you look at an image in a popular magazine article like the one above on the phenomenon we are all calling âno-codeâ software development, you might gain the impression that things are as simple as writing a diagram on a whiteboard to create a complex application. After all, this illustration shows how easy it is to use!
And indeed, no-code â or the ability to add programming logic through declarative syntax or to manipulate items in a user interface rather than relying upon traditional âcode-basedâ developer tools â is blowing up in popularity.
Why is no-code popular?
No-code (or its friendly cousin, âlow-codeâ) aims to reduce the high cost and long timeline of software development. The basic idea is to broaden the surface of who can do software and to make the outcomes more accessible to a âcitizen developerâ within companies rather than limit it to professional devs. Thereâs lots of promise to this approach, as low code/ no-code platforms have the potential to reduce the development time by 90% (source). In 2019, Gartner estimated that 65% of all app development would happen with no-code tools by 2024 (source).
Why does this seem plausible? For a lot of types of development, moving complicated, expensive development to lower-skilled employees speeds up the ability to develop and the speed to delivery for many types of applications that used to be available only to professional developers. Many of the headaches involved in software development are resolved with no-code, including hosting, security, debugging, accessibility and scalability. Some of the most valuable companies in the world have been built to address this market.
Yet thereâs a secret here underneath the shiny outer wrapper of âyou can do anything in no-code.â Itâs that the basics of a program that does computer things is computer instructions. Said another way, the most high-performing no-code solution will look (logically speaking, at least) a lot like high-performing code. Computers are kind of dumb. Most of the time they do exactly what you tell them to do. Your logic might need guardrails.
Meh, I donât need to know logic to get stuff done
âI donât need to worry about this stuffâ, you say. âAny competent product will anticipate what I need to do and protect me from the dumbest stuff.â Youâre not wrong. Unless you tell it how to behave, though, a product might default you into a lowest-common-denominator version of what you intended.
A problem exists today with the mindset of âyou can do anything in no-codeâ without a companion task to figure out âyou need to think about how you want to do that thing in no-code to make it run efficiently.â Many systems that you connect with no-code have no knowledge of each other without a shared data concept or a shared data model, and the systems are not expected to share enough data to solve the problem.
As a sales operations professional, this challenge is compounded by the business logic embedded in the tasks youâre asked to fulfill. Take a simple example of how to match the account of a company in Salesforce with the name of a company that you receive from a field marketing download from a webinar.
A version of this flow might look like this:
Simple, right? Maybe. Inherent in this diagram is a lot of embedded knowledge you need to have to do this process right. You lean on the system to make these decisions for you under the covers, you describe the exact process to map your accounts, or you need someone else to build interoperable logic you can plug into and use in your environment.
As a person trying to solve a problem, what are you supposed to do? You have many interconnected systems that donât really know all that much about each other. They know how to connect ⌠and then youâre on your own. Building a diagram of your logic lets you involve other stakeholders in the business to reach a shared destination.
You need a signpost to know where you are going
Building no-code logic is like building the route for a trip, except you are mapping data and systems instead of getting in your car, on your bicycle, or riding public transit or car-share and going somewhere. The reason you are able to use multi-modal transportation to navigate effectively in a city is that all of the pieces work together and that many shared assumptions ensure that itâs possible to go somewhere, to know where youâre going, and to accurately predict where you end up.
Traffic systems depend upon shared standards:
roads, pathways, and transit to get us from one place to another
laws and shared expectations to define how people co-exist on those pathways
dispute resolution and incident management to solve unexpected problems
No-code applications require shared agreement to operate well:
a shared data model, not just connective tissue
a âpromiseâ for how to behave in other applications. One way to enforce this on a system level is the use of an API to exchange information, and a missing piece of many APIs is a combination of discoverability (whatâs possible) and documentation (what happened/whatâs happening)
a way to remediate problems when they occur by tracking what you were trying to do, what happened, and what was done next.
There will be traffic jams â and unexpected outcomes â but having built-in remediation efforts to resolve these issues will make it possible for you to debug the logic in your no-code applications and share that process with the rest of your organization.
Whatâs the takeaway? Building a successful no-code application depends on a solid underpinning of logic. This means that part of the planning for any no-code effort is to write down what you want it to do (sounds simple, and most donât do it). Sharing this vision with other stakeholders in your environment increases the chance that your no-code application will not be a no-code silo.
Links for Reading and Sharing
These are links that caught my đ
1/Â âShow me a thing that looks like the Rocky Mountainsâ -Â Janelle Shane, who spends a lot of time training AI computer models how to do things, has a new post on building imaginary landscapes. It turns out that AI can now take a phrase input and create a look-alike image based on training data. This is in itself is not that unusual, but the images are getting better and better. Computer models that predict look-alike matches of many different things are the future of forecasting. We will be doing more đ and đ in the future.
2/Â Laws to live by -Â Youâve heard of Murphyâs law, but have you heard of Parkinsonâs Law (time expands to fill an available schedule) and more? Dave Kerr has created a helpful compendium of developer-friendly axioms. They are not only useful for cocktail party banter when we have those again, but also helpful reminders to prevent you from wasting time, effort, and energy.
3/Â Building a Personal CRM -Â as someone who worked for a team that built a Personal CRM to better manage contacts and relationships, I really appreciate Jakob Greenfeldâs system for keeping in touch with people. This is a perfect example for building process that reinforces behavioral nudges. Keeping in touch with people doesnât happen automatically, yet doesnât require a lot of effort at any one time. The key is consistency. Why not let a computer help you with that?
What to do next
Hit reply if youâve got links to share, data stories, or want to say hello.
Iâm grateful you read this far. Thank you. If you found this useful, consider sharing with a friend.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a âtoy.â -Â Chris Dixon