Apparently ...

… the thing I call TDD might not quite be TDD. Also some speculation, and some other speculation. Pure musing no code.

TDD or not TDD?

On Kent Beck’s substack, Tidy First (go there, subscribe, read, think about what you read), Kent has written “Canon TDD” to clarify just exactly what TDD is. As he is the one who coined the phrase and wrote the book, I think he gets to say what it is, and is not, and I want to use the term properly. So we need to talk about what I do and to consider whether I should call it TDD or not.

Now given what happened to the term “Agile Software Development”, I think we’re lucky if people saying they’re doing TDD even write any tests at all. Resorting to definitions to settle issues is fraught with peril, because terms mean what people think they mean, not what some old bearded dude wrote in a dictionary. But we try, we do try, to be precise in what we try to teach.

Historically, I think of TDD as the Red / Green / Refactor cycle: write a test, make it run, optionally refactor. Kent has clarified that the scenario list is important.

Here are things that I do that are not quite like what Kent says in Canon TDD:

I don’t always make the list.: I do not always write down a list of scenarios that I want to cover. If I’m programming in public, here in an article, I will usually tell you what I’m about to try to do, but otherwise, on my own, I generally do not. I generally just pick a thing out of my brain and start. This is made easier for me because even these long 300 article programs are pretty simple and well defined; because I generally only plan one step ahead; and because I am sure that another issue will be brought to mind shortly.
I don’t always write just one test.: Sometimes I’ll write more than one test, especially if the tests seem similar. Sometimes, rarely, I will write the name of a test and assert False, which kind of replaces the making a list step above. If I habitually did that for all the scenarios I could think of, I would consider that to be a list and claim that I was meeting the definition and the spirit of canon.

I think I do pretty well with the rest, that is, I make the test run, keep all the others running, refactor as I see fit, and continue until I reach a point I can call done, when my mental list runs out.

What should you do? I keep telling you and telling you, I am not the boss of you, and I try not even to give advice. It’s your job to consider as many ideas as you can, and to build up your own set of practices that help you deliver software in the fashion that works best for you.

What will I do? I think I”ll probably keep referring to TDD, and I’ll try to make it clear occasionally if I deviate from Canon. I claim no inventions whatsoever in the “Agile” canon and I try to follow what I’ve learned and to give credit to those who have helped me learn.

That said, just as I say that you should use the practices that work for you, I do the things that seem to work for me, in the style that I find works best, given my occasional deviations, slips, falls, mistakes, errors, and occasional good moves.

Speculation: Do I program differently?

From a number of conversations with other developers, I am coming to the notion that I program differently from many or most of them, in a way that might be notable. Part of it relates to a description of two kinds of novel writers, Plotters and Pantsers. Plotters figure out the plot before they write. Pantsers (think flying by the seat of the pants) just start writing and the story goes where it goes.

I certainly confess that these articles are pure pants. (Yes, my UK brothers and sisters, I do know what that means in your language, and embrace it.) I only have the most vague notion of where a morning’s article will take me and I would say that more than half the time, it takes me somewhere quite different from where I thought we’d go.

My programming, I think, is somewhat similar. I believe that I do less up front planning than many people do, and that given a plan, I follow it less rigorously than many do, that I abandon a plan sooner than many do, and that I generally just wander in the direction that I feel is good.

And it seems always to work out pretty well.

Even if I gave advice—which I do not—I would hesitate to advise anyone to emulate that aspect of how I work. But I do speculate that there is something useful behind it.

First of all, I have consciously tried in the years of this century to do as little up front design and planning as I possibly could, just to see what would happen. Because XP seems to call for less up front commitment, I wanted to see how far we could push it.

Second, I think that my general approach to math and programming has always been more intuitive than analytical. I was always best at math classes where we proved things, and where problems were solved mostly by insight, seeing which theorems applied. I did much worse at classes where lots of practice and calculation was required. I was terrible at integral calculus because you basically had to memorize and apply lots of strange formulas. So I think my brain is oriented toward pattern recognition more than toward detailed analysis.

Third, I have six decades of programming experience. I’ve seen a lot in that time. I’ve seen things you people wouldn’t believe … Attack ships on fire off the shoulder of Orion … I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments are integrated in my mind, and ideas come to me when I need them, almost always. (No, I do not embrace the “time to die” part of that most excellent scene. Today is not that day, I fondly hope.)

In recent times, you’ve seen me falter when I needed to analyze the details of some complicated thing. Would I have been better at that a half-century ago, or a quarter-century? Am I losing a step? Possibly, but old age and treachery make up for it quite often.

I’ve particularly noticed the difference when observing GeePaw Hill programming. He very clearly has more of a place in mind, more of a way the code “has to be”, than I do. I would also say that, modulo an occasional flash of brilliance on my part, he’s a better programmer than I am. Is it because he has those things in mind and I do not? In fact, I don’t think so. I think that, at least sometimes, he might do better to let go of some preconceptions. And I think that what’s left of his brain is a better programmer than what’s left of mine.

Overall, though, we all have to find our own balance, given how our mind works, and given what’s in there. If we just know something, we can go with it. If we don’t, we need to look it up or work it out, often “on paper”.

Which brings me to one more difference from many folks. I am inclined to work out more things in code than many folks. That’s a matter of intentional habit change over past years, because I am and have always been inclined to speculate about things and to argue from speculation, and I learned, at Kent’s hands, to “let the code participate in design discussions”. We were admonished that any time a design discussion went on for more than 10 or 20 minutes, it should be settled by doing an experiment. So there again, I worked to change my habits, and now I turn to a code experiment very quickly.

So … I speculate that my programming style is different from that of many of you. Do you find that to be the case, or not? I’d love to hear from you about it.

Speculation: Space Invaders

This morning, I was thinking about Space Invaders. The original game cost between $2000 and $3000 per console. The 8080 processor could address a maximum of 64KB. My version runs on an M1 MacBook Air for which I probably paid around $2000, with 16GB of memory. I have 250 thousand times more memory than the original console! The 8080 cycled at 2MHz, requiring 4 or more cycles per instruction. My Air cycles at over 3000 megahertz and instructions usually compete in one cycle. So the Air is probably 6000 times faster than the original 8080 game.

My big monitor was extra, but I’m still certainly under the $3000 wire for the original game.

The original game was written in assembler, mine is in Python. The original is very tight code and uses nothing more sophisticated than a function call. Mine uses objects and a few somewhat advanced notions such as list comprehensions, abstract classes, and so on. With expanded hardware like that, we can work at an entirely different scale.

Even more interesting than my M1 Air is the Raspberry Pi. An 8GB Pi costs about $80. For $270 you can get this cool Picade console:

picade game console

A suitable monitor would cost about $120. For around $500 you could build a dedicated Space Invaders console. It would be much smaller than the original: it would fit on a coffee table or your desk. Would it run my current version of Space Invaders? Would it be fast enough? I don’t quite know. Maybe I can figure it out. I do not plan to try it: I have a bad record of not building kits that I buy. But I am quite sure that it would be close to fast enough and that we could speed it up if need be. Want to pair with me to build one? Let me know, I might be up for it, if you do all the work.

Weirder Speculation

I was also speculating about how I might write Space Invaders in the smallest possible code, using nothing more than very simple data structures and functions. (One ought also to speculate about why anyone would do that.)

Could we represent an invader with just a couple of bits, maybe one for “alive”, and one for “waiting to move? Could we just bit-shift through the bits as we cycle?

It’s tempting, but I hope not tempting enough that I’ll try to do it. We have a computer that is a quarter million times larger and six thousand times faster. That changes the rules about how we should work.

Still … I do wonder what could be done …

Summary

I do plan to do a little code later today, and I’ll tell you about it then. This one was just pure musings. I hope that was OK with you.

See you next time!