Sometimes I’ll refactor, over time, from design A to design B, and then decide to refactor back to B, or something very much like B. That’s not a problem with the approach I’m demonstrating: it’s a feature.

What I’m Doing Here

OK, I admit that much of what I’m doing is making code and enjoying it. And, in a way, that is my point: it is possible to make code and enjoy it. If someone is making code and not enjoying it, they might possibly find inspiration here.

But there is a fundamental notion that I’m trying to bring out — no, to exemplify:

We can build software incrementally, adding capability and improving the design just in time—or almost just in time. We can keep the program’s increasing capability visible, essentially from day one, while growing the code’s design along with its features. We don’t have to go dark for weeks or months at a time while we build out infrastructure or perform some large but necessary design improvement. We can do it all incrementally, day by day, hour by hour.

I do that by picking various programs that are large enough to serve as demonstrations of how we do that, and small enough that one person can make progress over a period of weeks and months, always making it better, always making it more capable.

I’ve done that with games like Asteroids and Space Invaders. I’ve done it with a program that implemented extended set theory operations. I’ve done it in Lua, Kotlin, and Python. Anything that I could program at all, I could do in this fashion: I’m quite sure of that.

I freely grant that I sometimes stop working on something. Usually that’s because I’ve become bored, or see something more shiny, or am distracted by a squirrel. At least once, with Sudoku, I stopped because my fundamental notion of writing a solver without researching the topic was just not sufficient to the problem.

Sometimes I’ll refactor, over time, from design A to design B, and then decide to refactor back to B, or something very much like B. That’s not a problem with the approach I’m demonstrating: it’s a feature.

Things don’t always go well. Often I toss out a whole day’s work. Sometimes I’ll refactor, over time, from design A to design B, and then decide to refactor back to B, or something very much like B. That’s not a problem with the approach I’m demonstrating: it’s a feature.

Things will not go well on most every project and my point here is that that does not mean the end of the world. We can always move forward, adjusting the design slowly and smoothly to become what we need it to become.

And that’s why I write these words. That and the fun of it, of course.