Kitcoder for coders
Programmers might, understandably, be skeptical about the idea of end-users building working apps. This article looks at the thinking behind Kitcoder from the programmer's point of view.
You can make some pretty amazing things out of kits. The model airplane kit is a classic, but how about a real one?
It must be a pretty cool feeling to be up in the clouds and get to say “I built this myself”. But let's be honest for a minute—who really built it? A serious hobbyist can put this thing together, but what about the parts? Those are made by skilled professionals, with the resources of a commercial enterprise behind them.
A kit, then, is a way to split the task of building something in two: the engineering, and the assembly. It's the engineer's job to make sure the thing flies, while the assembler can make some customisations, but only within parameters given by the engineer.
The idea of software built by end users is a dream we've been chasing since the very dawn of the computer industry. We've had a few great successes, most notably the spreadsheet and database builders like Access or FileMaker, but we've had far more failures. Building working software is just plain difficult. It's a serious engineering discipline that demands training and experience. Amateurs will never build working software, in the same way amateurs will never build working airplanes. Unless they have a kit!
A kit sidesteps the problem that the hobbyist is not an engineer, by simply getting all the engineering out of the way before hand. In the same way, we can sidestep the formidable challenges of end user programming, but we do need to figure out end user customisation. There's no point in code kits that always fit together into the exact same software—why even bother? The key question is, can these kits be customisable enough to be useful, without being so customisable that everything breaks?
Before getting to that, let's start with a more fundamental question—what exactly are these software kits anyway? The idea of building software from parts has, after all, always been fundamental to programming. In particular, the metaphors of object oriented programming might suggest we make software from kits already. We have a bunch of objects, which we pull out of libraries, and connect together into working systems. There have even been attempts to let end-users take part, by putting a graphical user interface on top of the objects. I actually built something like that myself a long time back, but I've come to see this approach as mistaken. We don't make software out of objects. Have you ever even seen an object? It's like saying an electronics engineer builds things out of electrons. We build software from code.
Kitcoder is built on top of a code-generation language called Clarity. Clarity is essentially a template language, though rather more powerful than the ones you might be familiar with. A “part” in Clarity is simple a code template (or a collection of related templates). In the simple case parts are just like macros, but in more complex cases they can be complete “recipes” for implementing a feature that might need changes to more than one file, in more than one language. Parts also define connection points (simply, labelled insertion points in code fragments) so that they snap together in sensible ways to form working programs.
The Kitcoder app is nothing more than a graphical editor for Clarity, which in turn, is nothing more than a way of writing code without actually typing it out by hand. When someone is working in Kitcoder they are essentially “just writing code”, but two steps removed from the actual source files, working with parts instead of text.
Now that we know more clearly what these code-kits actually are, let's get back to that key question: can they be customisable enough to be useful, without being so customisable that everything breaks? An example would be useful, and the best example is probably the one that the project grew out of—building web based CRUD apps.
Anyone who's done any freelance software development in the past ten years or so, has very likely built a web based CRUD app for someone. At one point I remember being struck by the idea that the vast majority of all business software seems to be little more than a carefully crafted UI on top of a database. Building CRUD apps, it's easy to get the idea that once you've built one, you've built them all. It's the same thing, over and over.
That's not to say that building them is waste of time. Quite the contrary in fact. They can be incredibly valuable to a wide range of clients. And getting them right is not so easy either. From a purely technical point of view they might not be challenging, but from a design perspective it can be a lot of work to get them just right, and all that tweaking can end up very expensive for small clients. In other words they're right in the sweet-spot for code-kits: technically well understood and nailed-down, but demanding a lot of small customisations.
I believe this sweet-spot for kits is very big. In other words, there is loads of potentially great software that doesn't get built well enough, or doesn't get built at all, but from a technical perspective is almost trivial. What's difficult about these kinds of apps is not the coding, but the design. Code kits give designers the tools to work on them directly. ("Designer", here, is meant in the broadest possible sense—anyone with a clear idea of how they want the software to look and work).
For small and simple apps, it might be that the need for real programming is removed entirely, and “kit assemblers” can build the whole thing. In bigger projects where there is a full team, it may often be the case that some aspects of the software have this quality of being programming light, design heavy, and code-kits can be applied just where it makes sense.
Kitcoder is already at the point where it can be used as a builder tool for web based CRUD apps, and native mobile clients are shaping up to be no harder, thanks to amazing projects like React Native. I have found that if you keep things small and simple, it's perfectly possible to build this kind of software, from kits, with a high degree of flexibility, and without compromising the solid engineering principles that are captured in the parts.
The big question is how much further can the idea be taken. Only time will tell. Certainly, if untrained users are given too much power, they will shoot themselves in the foot, but that misses the point. A tiny fraction of the creative possibilities that we, as engineers, can explore, could be a game-changer for non-programmers, but even that doesn't quite capture it.
The big opportunity here, I think, is the potential for a new way to work together. The gulf of understanding that exists between software developers and domain experts is one of the most critical problems we face. It's easy to imagine lone users trying to do crazy stuff with code kits and getting completely lost. I'm sure it will happen. But imagine instead, a programmer looking at that broken attempt as a way of understanding where they were trying to go. Imagine then building some new parts that better match what was needed, and seeing what happens next. Every step is a chance for the software expert to better understand the domain, and the domain expert to better understand the software. That sounds like it could be a big idea. At the very least it's going to be fun finding out.