Who counts as an end-user programmer?
The category is much wider than it sounds. The word "programming" tends to put off most of the people who are already doing it.
- The finance analyst who wrote a nested spreadsheet formula.
- The ops lead who built a five-step Zapier automation.
- The teacher who set up a Notion database with rollups across it.
- The designer who wrote a Figma plugin to rename 400 layers.
- The parent who wrote a Home Assistant rule about the porch light.
None of them would call what they did programming. But each of them was telling a machine what to do on their behalf, which is really what programming is: describing what you want a machine to do later.
The spreadsheet is the most widely used programming environment ever built, and most of the people using it would say they don't program.
What is tailorable software?
Tailorable software is software designed to be adapted by its users after it ships. The term comes from computer-supported cooperative work research, where people kept noticing the same thing: a system installed across an organisation gets bent, quietly and constantly, by the groups using it. Systems that leave room for that bending tend to last. The ones that don't get worked around, and are eventually replaced.
Tailorable, malleable, end-user-modifiable, customisable, composable: the words change, but the argument underneath them stays the same. Software works better when the people who live in it can shape it.
How is end-user programming different from malleable software?
They describe two halves of the same thing. End-user programming is the activity, and malleable software is the property of a product that makes the activity possible. You don't really get the first without the second, and a malleable product that nobody builds anything in is just an unused surface.
The other difference is where the work happens. Historically, end-user programming meant leaving your software behind and going somewhere else: a macro editor, a scripting console, a spreadsheet. Malleable software moves the activity back inside the product, onto the live records, with whatever access the person had before they started.
Why is it different this time?
The old bargain was that you could change your software as long as you first became a programmer. That asks a great deal of someone who only wants to solve one problem, and it goes a long way towards explaining why forty years of research produced spreadsheets and not much else that stuck.
What changed is the interface. When you can describe what you want in plain language and get something working back, most of the expertise that used to be required falls away. The vendor still draws the boundary and still decides what data a change can reach, but the person with the problem no longer has to learn a language before they can solve it.
That's the bet Rough is built on, and we've written about it at more length here.
Where to read next
- Lieberman, Paternò and Wulf, End-User Development (2005). The standard reference, and the clearest case for why people who aren't programmers should still get to build.
- Clay Shirky, Situated Software (2004). On purpose-built software for a small, known group, and why it beats the general case more often than you would expect.
- Ink & Switch, Malleable Software (June 2025). The modern restatement of the argument.
- What is malleable software? The definition, and how it differs from configuration and low-code.
- The malleable software directory. Products with a malleable surface, and where to find it in each one.