Addition, Multiplication, Integration

How do we build software faster?

I’ve been grappling with this question for a while now, because I’m just full of ideas, new things I want to try, and I’m held back with the speed I write software at. I look back through the history of software, or of any technological development, and I realize: this need not be so!

We can write software faster, we’ve been doing it all along. Things that used to take long and arduous periods of time to write are done quicker now, to an extent. But I want to do better, even faster, and I want to improve everything along the way. I don’t want my ideas to be limited by unnecessary bottlenecks.

Why the hurry?

With a fulltime job and a fulltime personal life, I give myself about one hour per day to work on my own personal projects. I start my mornings by coding for an hour or so, on something I really care about before I head off to work (it’s a great habit to be in, by the way, because it starts the day off on a really positive note, leaving me energized for the rest of the day). Being limited to one hour per day forces me to be focussed on my work, too. Although one hour per day isn’t a lot of time to devote to all the projects I want to get through (at last count, I’ve got about 10 in the backlog), it’s really a hard limit for me now. So if I want to write software faster, something else has to give, and that’s got to be from the software itself.


The most obvious way to work faster is to build on the work of others, and for software developers the most obvious way to do that is to use components built by other developers. Open (or closed) source projects and objects created by other developers is a fast way to add new things to a project so that I don’t have to. I can depend on libraries written by others, and I can’t depend on others, but I’ve been at this long enough I’ve developed a keen eye for telling the good from the bad.

According to most developers, we’ve created a solution to allow for better sharing of code. We’ve got object oriented systems, and we’ve got repositories full of them strewn across the web. GitHub creates a social network around them, and package managers allow us to install them at a whim to our projects. I can’t help but feel these solutions all fall tremendously short, for reasons I’ll detail in a later article.

Suffice it to say, using components from other developers does improve how fast we can write software. It’s like a form of addition. Work on my project has been added to for free.


If adding components from other developers is like addition, it follows then that I can work even faster if I work with other developers. This is like multiplication, a collaboration where we collectively work harder because there are more of us doing the work.

I’d even consider something so superficially simple as bouncing ideas off another developer to be a form of collaboration, because it allows me to get outside of my own mind.

Derivation and Integration

The ways I’ve discussed so far are all helpful methods of building software faster, and I’ve been using them recently to great success, I know there is an even better way, in addition to those already mentioned. This way sort of transcends all the other ways and affects my ability to write software at all levels.

How do we really get faster at making software? Well we have to eliminate the bottlenecks and by far the biggest bottleneck for any software developer is thinking. Thinking is what takes up the vast majority of our time. I think there are two main kinds of thinking a programmer has to do, one good and one bad. We need to create new ways to shift the balance in the good direction:

  1. Good thinking is thinking about the core problem trying to be solved. This means things like the overall problem, the algorithms needed to model a system, the intention of the user the developer is trying to meet, etc. these things are necessary to think about, they’re what people want to solve, but they are encumbered by…

  2. Bad kinds of thinking is not about bad thoughts, just counterproductive ones. These are the “tricky bits” where the developer is forced to think about implementation problems, think about the minutiae of either the system or how to program it.

    These are things like bugs that need to be understood and fixed, but also trying to reason in unfamiliar or unintuitive ways (for example, thinking in higher order dimensions, dealing with non-human scales, changing coordinate spaces), anything that causes a person to slow down and have to reason about something before they can continue onto their “good/real work.”

If code sharing is addition, and working with others is multiplication, then this becomes like a form of differential calculus.

I want us to contribute to tools that will minimize the amount of time we spend dealing with the rough kind of thinking. I want those sorts of details to be trivialized, so that the good kind of thinking becomes more natural. That’ll let us spend more time on the problem domain, which will open up all kinds of new ways of thinking.

I’m not exactly sure what those sorts of tools look like yet, but I have some hints to help me find them (and I’d love to hear how you think we can find them, too):

  1. Any time you’ve got to draw something out on paper (geometry, visualizing data or program flow, etc.) is probably a good hint we could develop a tool to help reason about this problem better.

  2. If it’s a common source of bugs for programmers, this is probably another candidate (off-by-one errors, array counting, regular expressions, sockets or other kinds of stream-bound data, etc.).

  3. Any time where it takes a lot of tries and tweaks to get something just right. If you’ve spent too much time trying to tweak or visualize how an animation or graphic should look, this might be a great place to look for creating a tool for better reasoning about it.

I’ve got some preliminary work done on this, but nothing I’m ready to show off quite yet. In the meantime you might like to check out the Super Debugger, as a crude attempt until I’m ready.

These certainly aren’t the only pain points we software developers need help reasoning about, but it’s a start. And that’s just for software developers. I’ve completely left out everybody else. Every physicist, every teacher, every architect, every doctor, every novelist. These are all domains which could benefit greatly from new ways of reasoning to help them do their work better. But I think we should start with the problems we’re having before we can begin to help anyone else (hint: we shouldn’t be solving anybody’s problems, we should be giving them the tools to create their own way of thinking and reasoning better. It would be presumptuous to assume we software developers knew how to fix the world’s ills. But we can enable them to do it.).

Speed of Light