Category: technical-debt

Usage changes. Language is usage. Language changes, not necessarily for the better, in my opinion.

Let's pretend we care about that inefficiency in drawingOrder. Also a momentary loss of momentum.

I don't usually predict an outcome but today I think something good is going to happen. Let's find out.

Today, more refactoring to remove connections between dungeon objects and their tiles. And, as always, some thinking.

Two starting ideas: Quest, and removing duplication in the dungeon objects. These are not unrelated. And: as so often happens, we go in a surprising direction.

Let's set some direction. I'm concerned that I'm off track on what is of value to work on. Possibly it's residual fear from decades ago.

I think we'll do a bit more on our 'Making App', the part of our code that helps us make the 'Shipping App', the product we ship. (We decide to bless this effort.)

One more challenge in the class/method finder, then maybe we'll think about what we actually need in our Making App.

I've had an idea about a change--perhaps an improvement--to the class/method reporter. As I write this, even I don't know what happens next.

More work on our nascent Making App. Dave1707 has some interesting tricks in his programs. And we have a fine small example of refactoring 'legacy' code.

Dave1707 from the Codea forum provided an interesting program. I would like to bring it under control.

Dave1707 wrote a nice demo showing how to get project information in Codea. Let's think about what it tells us. No code, just think

A new day dawns. New chai. Consolation from the Zoom Ensemble. Technical debt. And another run at combat.

In which our intrepid author makes a grievous error: disagreeing with Kent Beck. Or does he?

Today we'll try to fix the collision logic to accommodate our origin changes, and to make the invaders explode.

Some thoughts from Twitter on 'technical debt', what it is, what it isn't, and why we avoid it.

A couple of people asked me to list all the technical skills required in order to do Agile Software Development. I can't do that, but I can do this.

YAGNI can be a legitimate way to go fast at minimal cost. Skimping on the practices that support YAGNI? That's a mistake. Technical Debt? Not the same thing.

Some words and pictures about the various notions of 'technical debt', or, as I like to call it, wishful thinking.

I've been trying to learn a 3D drawing program. Yesterday I noticed that I was working but not learning.

Over the past few days, an ancient twitter thread accidentally revived, talking about how you don't need quality code when you're just validating assumptions. What do the ants have to say about that?

In which we discuss the technical debt metaphor, bright code, and the inevitable decline of civilization.

There has recently been a lot of noise on the lists, and questions at conferences, about putting refactoring "stories" on the backlog. Even if "technical debt" has grown up, this is invariably an inferior idea.