April 8, 2020

When you're building some MVP or SLC it's tempting to over-think technical choices early on. It's tempting to build in all kinds of features and infrastructure.

"People might want a PDF," you think to yourself, "so I'll also build and deploy a PDF rendering server!"

"I'll need a way to measure everything my ten million customers are doing at scale so I'll deploy this elastically scaling mega analytics doodad framework server and hook it up to every user action in my app!"

cricket.gif

It's much easier to imagine new features than it is to actually build them. Before you know it there is a vapourware castle shimmering on the horizon.

I've found a useful thought pattern to combat this type of over-engineering. For every technical question just think to yourself:

What will my zero customers think of this?

When you are building the first version of something there are literally zero users. Unless it is the core function of the thing you are building, making a PDF rendering server or deploying a giga-scale analytics system is not what you should be doing. Your zero users don't care about those things! Getting even one person to actually use your thing and tell you if it's good or not is what you should be doing. Talking to people and asking them what they need is what you should be doing.

Let's protect the most scarce resource of all: our own time. At the start of the project let's make a bee-line towards shipping the best possible implementation of the core function of the software so we can find out if its useful and good.

March 15, 2020

Recently I was teaching one of my kids a bit of web coding. This is way more complicated than it should be. There are so many moving parts - configuration, build systems, editors, hosting requirements, certificates etc. just to get a simple web app running. Why?

I thought back to when I was learning to code with my mother on our Apple IIe. The computer was ours. The code was ours. The data was ours.

fdf0e437a027e6f3f3622f67d65e0ef0.png

I thought back to shareware. First diskettes and then FTP. I thought about my first website and those first Multi User Dungeons. Nethack and newsgroups and bulletin board systems. Trading ware with friends. I remembered running Linux for the first time on a Pentium. The freedom and power of getting to do what you want with your computer and a network connection. How can we take our computers back?

I started thinking about what a personal computing platform would look like today. A platform that a kid could jump right into and start coding. A platform where a kid could build cool stuff without asking for permission. Systematic convex tinkering with computers. Where they could own their software, and their data, and their device.

A way to make, run, and share web applications without needing site hosting, SSL certificates etc. An app repository and a text editor in a single web app. A way to share apps peer-to-peer, directly between trusted friends, family, and associates.

Then I re-read this:

  • Personal computers – in the original visions of many personal computing pioneers (e.g. many members of the Homebrew Computer Club), the PC was intended as personal property – the owner would have total control (and understanding) of the software running on the PC, including the ability to copy bits on the PC at will. Software complexity, Internet connectivity, and unresolved incentive mismatches between software publishers and users (PC owners) have substantially eroded the reality of the personal computer as personal property.

This desire is instinctive and remains today. It manifests in consumer resistance when they discover unexpected dependence on and vulnerability to third parties in the devices they use.

Nick Szabo in Trusted Third Parties Are Security Holes.

This is the important thing. It has to be self sufficient. It has to work properly whilst depending as little as possible on third parties.

c02481139c1de01523209cad3767a3ff.png

Last Monday I started building this. It's called Slingcode. With it, you can write, run, and share your own web applications directly in the browser. You don't need any build system, hosting provider, SSL certificate, or any thing else. You don't even need an internet connection. Just a web browser and the single HTML file containing the Slingcode web app.

Stay tuned.

March 14, 2020

Last week I entered the 7 Day Roguelike Challenge. I used the the px3d game engine with Blender and ClojureScript to build a game prototype.

Screenshot of the game

forest-moon-bear.gif

Screenshot of the game

Screenshot of the game

Feb. 19, 2020

I've been thinking about this idea lately of software written for small groups of mutually-trusting humans, like families. I like to think of this type of software as "sub-Dunbar software", named after Dunbar's number:

suggested cognitive limit to the number of people with whom one can maintain stable social relationships

Sub-Dunbar software is any software that is optimized for groups of this scale and intimacy. It's cozy.

337754d47c018b8c5e0b1378e4791c9b.png

Photo by Dan Gold on Unsplash

Here's some reading related to this idea:

it would not surprise me if we moved away from "public square" online dynamics to "small intimate online dinner party" online dynamics.

Tommy Collison

I didn't know it at the time, but todoMini is an example of this type of software. I wrote it for my family, not for scale, and it won't change. I hope to build more sub-Dunbar software.

a146ba6154b224489a665333822b241a.png

Photo by Kelsey Chance on Unsplash

Jan. 22, 2020

Last week I was on the Gold Coast for Linux Conf AU. I gave two talks:

Piku: git push deployments to your own servers

px3d: a free software browser based pixel 3D nano-engine in ClojureScript

Other talks

I've compiled a list of talks I got a lot of value from which you can find on Twitter.

gold-coast.jpg

Enjoy!