Inyesterday’s post, I talked about how I want to spend a good chunk of the rest of my career looking for a better and more human-centric way of developing software, in part based on Mel Conway ‘s ideas.
There are an endless amount of different parts to thispuzzle, and hopefully I will uncover all of them on this blog. But because I am very much someone who needs to play around with ideas to make any sense of them, I’m also going to be doing a bunch of small code experiments as I go. Tonight, I did the first one of those, which is so simple that it’s barely worth sharing:
(Should you wish to make with the clickity-clack yourself, try the live version of this program in your browser. But all it does is what you see in the GIF above!)
The reason why I built it was roughly to give myself a starting point for exploring Conway’s eight principles for a software construction toolkit, which involve having a system with with a single visible program representation (i.e. a unified system which does not separate source code from the objects it represents). This system would also need to be symmetrical, always on, transparent, predictable, immediate, interactive, and reversible.(seeyesterday’s post for an explanation of that and a link to Conway’s work)
I am nowhere near ready to build development environment UIs that have all of these properties, because I am an absolute beginner at UI design to begin with. So, my early experiments are going to focus on UI development in general, as I attempt to build little toys that incorporate as many of these design principles as possible.
Here’s a quick teardown of the current demo, which is quite contrived but will help me figure out what I should work on next…
This programis interactive , and changes happen immediately . You can’t see mouse clicks happening in the GIF, but they do work basically as you’d expect them to, so it is mostly predictable. It also is transparent in that you don’t need to think about the events and data being modeled under the hood, instead you can think of the circles as buttons which then light up the main display in that color. And so your brain can make a direct association between pressing the colored buttons and the outcome.
The always on property is not applicable to this early example, because all of the components are visible when you first open the program up, and there’s no mechanism for adding or deleting components from within the application. There also isn’t yet a meaningful symmetry between the development tool and the software being produced with it, because well… this tool serves no useful purpose yet.
And for things that this simple demoin theory could have but does not, it lacks reversibility because there is no undo operation that would allow you to revert to a previous state. It is also not a unified system because the source code was written in advance and then the interaction happens via the browser UI. Technically speaking the code could be hot-patched through browser developer tools, but that probably shouldn’t count because it’s not an intentionally designed mode of interaction with the tool.
My next experiment will probably be to take some of these properties that were missed in this initial demo and work on incorporating them. But I also have a ton of other stuff to talk about, so I’m not sure if that’ll be my next post or not.
This one was mostly about planting a seed.