Making and Tool-Making
Developing Citybound is a pretty insane endeavor, and has been, from the very beginning. Endless trial and error. Extensive study of whole fields of research. Doing things from scratch. Having to do things differently than anyone ever has, because no one ever faced the exact challenges I took on.
What keeps me going is an unwavering curiosity: “what if we pretended this was actually doable?” I am further fueled by the generous mental and material support of the kind, loyal and ever-interested Citybound community. I am distracted by having to juggle jobs from time to time, to re-earn my freedom to do what I love. This is unavoidable.
But there is a much bigger distraction: the incredible friction of bad tools, abstractions and practices in software development.
This is what I feel I spend most of my energy on: developing Citybound despite my tools, against the limiting assumptions of their toolmakers.
I don’t want to give too harsh of a critique: in the software culture where these tools were made, they do a good job, and are getting better.
But Citybound already challenges this cultures’ assumptions of what a project can be. It’s a game. And a game engine. That’s more like a distributed simulation engine. That runs in the browser. And on a server. That covers diverse topics and relies on solutions otherwise only found in cutting edge research. Traffic simulation, economy simulation, geospatial geometry trickery, procedural architecture. None of these tools were made for all that.
The tools that are failing me to some degree include:
- Code editors
- Programming languages
- Note taking and documentation tools
- Build tools
- Bug tracking tools
- Community sites, mailing tools, this blog
Worse than their individual minor shortcomings is how disconnected these tools are.
The friction within and between these tools is the main limiting factor of how much of this project I can keep in my head at once. And that itself is the main limiting factor of Citybound development speed.
Low friction is not just “slightly better” it’s the dramatic difference between a chore and a light task; an impossible challenge and merely a tricky problem.
If you know me by now, I’m sure you understand that I wouldn’t complain about all of this, if I didn’t think it could be fixed.
Yes, I think I can build better tools. Tools for complex projects like Citybound.
I’m in a unique position of both needing better tools, knowing typical requirements, and having gathered enough technological, design and “inventing” skills to make them work.
And if I seriously believe my point about the importance of low friction, I should be able to find economic advantage in building better tools, and then building Citybound faster using these tools.
That sounds like a bit of a gamble. It’s not entirely clear if and when that would pay off. Luckily it’s not all-or-nothing: I can build small tools, that a already solve some of my problems better. And then I grow them from there.
I’ve been thinking about this for over two years now. Talking to Alan Kay gave me the final nudge.
I am starting to build better tools, so I will be better at building Citybound.
What I’m tackling first:
- Note taking and planning
- Project and code documentation
- Deep community interaction
That’s where I see the lowest effort for the highest impediment of friction. And the technology behind it paves the way for some of the more involved problems related to programming itself, but those will be tackled later.
Like with Citybound itself, I would love to involve you as early as possible. Expect to hear about my progress with my tools, alongside my parallel development progress on Citybound itself.
I don’t have something to show just yet, but as soon as I have, you will be the first to see it!
Like always, I’m looking forward to hear what you think!