Software Forestry 0x05: Cutting Trails

The lived reality of most Software Foresters is that we spend all our time with large systems we didn’t see the start of, and won’t see the end of. There’s a lot of takes out there about what makes a system “Legacy” and not “just old”, but one of the key things is that Legacy Systems are code without continuity of philosophy.

Because almost certainly, the person who designed and built in the first place isn’t still here. The person that person trained probably isn’t still here. Given the average tenure time in tech rolls, it’s possible the staff has rolled over half-a-dozen or more times.

Let me tell you a personal example. A few lifetimes ago, I worked on one of these two-decade old Software Forests. Big web monolith, written in what was essentially a homebrew MVC-esque framework which itself was written on top of a long-deprecated 3rd party UI framework. The file layout was just weird. There clearly was a logic to the organization, but it was gone, like tears in the rain.

Early on, I had a task where I needed to add an option to a report generator. From the user perspective, I needed to add an option to a combobox on a web form, and then when the user clicked the Generate button, read that new option and punch the file out differently.

I couldn’t find the code! I finally asked my boss, “hey, is there any way to tell which file has which UI pages?” The response was, “no, you just gotta search.”

As they say, Greppability Is an Underrated Code Metric.

(Actually, I’ve worked on two big systems now where I had essentially this exact conversation. The other one was the one where one of the other engineers described it as having been built by “someone who knew everything about how JSP tags worked except when to use them.”)

So you search for the distinctive text in the button, or the combo box, or something on the page. You find the UI. Then you start tracing in. Following the path of execution, dropping into undocumented methods with unhelpful names, bouncing into weird classes with no clear design, strange boundaries, one minute a function with a thousand lines, the next minute an inheritance hierarchy 10 levels of abstraction deep to call one line.

At this point you start itching. “I could rewrite all of this,” you think. “I could get this stood up in a weekend with Spring Boot/React/Ruby on Rails/Elixir/AWS Lambdas/Cool Thing I Used Last”. You start gazing meaningfully at the copy of the Refactoring book on the shelf. But you gotta choke down that urge to rebuild everything. You have a bug you have to fix or a feature to deploy. But it’s not actually going to get better if you keep digging the hole deeper. You gotta stop digging, and leave things better for the next person.

You need to Cut a Trail.

1. Leave Trail Markers.

First thing is, you have to figure out what it does now before you change anything. In a sane, kind world, there would be documentation, diagrams, clear training. And that does happen, but very, very rarely. If you’re very lucky, there’s someone who can explain it to you. Otherwise, you have to do some Forensic Architecture.

Talk to people. Add some logging. Keep clicking and watching what it does. Step through it in a debugger, if you can and if that helps, although I’ve personally found that just getting a debugger working on a live system is often times more work than is worth it for the information you get out of it. But most of all, read. Read the code closely, load as much of that system’s state and behavior into your mind as you can. Read it like you’re in High School English and trying to pull the symbolism out of The Grapes or Wrath or The Great Gatsby. That weird function call is the light at the end of the pier, those abstractions are the eyes on the billboard—what do they mean? Why are they here? How does any of this work?

You’ll get there, that’s what we do. There’s a point where you’ll finally understand enough to make the change you want to make. The trick is to stop at this point, and write everything down. There’s a “haha only serious” joke that code comments are for yourself in six months, but—no. Your audience here is you, a week ago. Write down everything you needed to know when you started this. Every language has a different way to do embedded documentation or comments, but they all have a way to do it. Document every method or function that your explored call path went through. Write down the thing you didn’t understand when you started, the strange overloaded behavior of that one parameter, what that verb really means in the function name, as much as possible, why it does what it does.

Take an hour and draw the diagram you wish you’d had. Write down your notes. And then leave all that somewhere that other people can find it. If you’re using a language where the imbedded documentation system can pull in external files, check that stuff right on in to the codebase. Most places have an internal wiki. Make a page for you team if there isn’t one. Under that, make a page for the app if it doesn’t have one. Then put all that you’ve learned there.

Something else to make sure to document early on: terminology. Everyone uses the same words to mean totally different things. My personal favorite example: no two companies on earth use the word “flywheel” the same way. It doesn’t matter what it was supposed to mean! Ask. Then write it down. The weird noun you tripped over at the start of this? Put the internal definition somewhere you would have found it.

People frequently object that they don’t have the time to do this, to which I say: you’ve already done the hard part! 90% of the time for this task was figuring it out! Writing it down will take a fraction of the time you already had to spend, I promise. And when you’re back here in a year, the time you save in being able to reload all that mental state is going to more than pay for that afternoon you spent here.

2. Write Tests.

Tests are really underrated as a documentation and exploration technique. I mean, using them to actually test is good too! But for our purposes we’re not talking about a formal TDD or Red-Green-Refactor–style approaches. That weird function? Slap some mocks and stubs together and see what it does. Throw some weird data at it. You’re goal isn’t to prove it correct, but to act like one of those Edwardian Scientists trying to figure out how air works.

Another Forest I inherited once, which was a large app that customers paid real money to use, had a test suite of 1 test—which failed. But that was great, because there was already a place to write and run tests.

Tests are a net benefit, they don’t all have to be thorough, or fall into strict unit/integration/acceptance boundaries. Sometimes, it’s okay to put a couple of little weird ones in there that exist to help explain what some undocumented code does.

If you’re unlucky enough to run into a Forest with no test runner, trust me, take the time to bolt one on. It doesn’t have to be perfect! But you’ll make that time back faster than you’d believe.

When you get done, in additional to whatever “normal” Unit or Integration tests your process requires or requests, write a really small test that demonstrates what you had to do. Link that back to the notes you wrote, or the documentation you checked in.

3. A Little Cleanup, some Limited Refactoring

Once you have it figured out, and have a test or two, there’s usually two strong responses: either “I need to replace all of this right now”, or “This is such a mess it’ll never get better.”

So, the good news is that both of those are wrong! It can get better, and you really probably shouldn’t rework everything today.

What you should do a little cleanup. Make something better. Fix those parameter names, rename that strangely named function. Heck, just fix the tenses of the local variables. Do a little refactoring on that gross class, split up some responsibilities. It’s always okay to slide in another shim or interface layer to add some separation between tangled things.

(Don’t leave a huge mess in the VC diff, though, please.)

Leave the trail a little cleaner than when you found it. Doesn’t have to be a lot, we don’t need to re-landscape the whole forest today.

4. Write the New Stuff Right (as possible)

A lot of the time, you know at least one thing the original implementors didn’t: you know how the next decade went. It’s very easy to come in much later, and realize how things should have been done in the first place, because the system has a lot more years on it now than it used to. So, as much as you can, build the new stuff the right way. Drop that shim layer in, encapsulate the new stuff, lay it out right. Leave yourself a trail to follow when you come back and refactor the rest of it into shape.

But the flip side of that is:

5. Don’t be a Jerk About It

Everyone has worked on a codebase where there’s “that” module, or library, or area, where “that guy” had a whole new idea about how the system should be architected, and it’s totally out of place with everything else. A grove of palm trees in the middle of a redwood forest. Don’t be that guy.

I worked on an e-commerce system once where the Java package name was something like com.company.services.store, and then right next to it was com.company.services.store2. The #2 package was one former employee’s personal project to refactor the whole system; they had left years before with it half done, but of course it was all in production, and it was a crapshoot which version other parts of the system called into. Don’t do that.

After you’re gone, when someone looks at the version control change log for this part of the system, you want them to see your name and think “oh, this one had the right idea.”

Software Forestry is a group project, for the long term. Most of the time, “consistency and familiarity” are more valuable than some kind of quixotic quest for the ideal engineering. It’s okay, we’ll get there. Keep leaving it better than you found it. It’ll be worth it.

🌲

You’ll be amazed what your overgrown codebase looks like after a couple months of doing this. That tangled overgrowth starts to look positively tidy.

But sometimes, just cutting trails doesn’t get you there. Next Time: The Controlled Burn.

Ten Years of the Twelfth Doctor

I missed it with everything else going on at the time, but this past August marks ten years since the debut of Peter Capaldi as the Twelfth Doctor Who, who is, without a doubt, my all-time favorite version of the character.

His take on the character boiled down to, basically, “Slightly Grumpy Aging Punk Space Dad”, and it turns out that’s exactly what I always wanted. Funny, weird, a little spooky, “kind” without necessarily being “nice”. If nothing else, the Doctor should be the coolest weird uncle possible, and, well, look at that picture! Perfection.

(This is a strange thing for someone who grew up on PBS reruns of Tom Baker to admit. But when I’m watching something else and wishing the Doctor would show up and kick things into gear, it’s now Capaldi I picture instead of Baker.)

Unlike some of the other versions of the character, Twelve took a little while to dial in. So it’s sort of appropriate I didn’t remember this anniversary until now, because this past weekend was the 10th anniversary of the eighth episode of his inaugural series, “Mummy on the Orient Express.” “Mummy” wasn’t the best episode of that season—that was easily “Listen” or “Dark Water”, but “Mummy” was the episode where I finally got what they were doing.

This is slightly embarrassing, because “Mummy” is also the most blatantly throwback episode of the year; it’s a story that could have been done with very few tweaks in 1975 with Tom Baker. The key though, are those differences in approach, and one of the reasons a long running show like Doctor Who goes back and revisits old standards is to draw a contrast between how they were done then vs now.

Capaldi, unlike nearly all of his predecessors, was a genuinely well-known actor before climbing on board the Tardis. The first place I saw him was as the kid that falls in love with the (maybe?) mermaid in the criminally under-seen Local Hero. But his signature part was Malcom Tucker in The Thick of It. The Thick of It is set “behind the scenes” of the British government, and is cut from the British comedy model of “everyone is an idiot trying to muddle through”. The Thick of It takes that model one step further, though, and posits that if that’s true, there must be a tiny group of non-idiots desperately keeping the world together. That’s Malcom Tucker, nominally the government’s Director of Communications, but in reality the Prime Minister’s enforcer, spin doctor, and general Fixer. Tucker is clearly brilliant, the lone competent man surrounded by morons, but also a monster, and borderline insane. Capaldi plays him as openly menacing, but less straightforwardly malevolent as just beyond caring about anyone, constantly picking up the pieces from the problems that the various other idiots in Government have caused. Capaldi manages to play Tucker as clearly always thinking, but it’s never clear what he’s actually thinking about.

Somehow, Tucker manages to be both the series main antagonist and protagonist at the same time. And the character also had his own swearing consultant? It’s an incredible performance of a great part in a great show. (On the off chance you never saw it, he’s where “Omni-Shambles” came from, and you should stop reading this right now and go watch that show, I’ll wait for you down at the next paragraph.)

So the real problem for Doctor Who was that “Malcom Tucker as The Doctor” was simultaneously a terrible idea but one that was clearly irresistible to everyone, including show-runner Steven Moffat and Capaldi himself.

The result was that Capaldi had a strangely hesitant first season. His two immediate predecessors, David Tennant and Matt Smith, lept out of the gate with their takes on the Doctor nearly fully formed, whereas it took a bit longer to dial in Capaldi. They knew they wanted someone a little less goofy than Smith and maybe a little more standoffish and less emotional, but going “Full Tucker” clearly had strong gravity. (We’ve been working our way on-and-off through 21st century Who with the kids, and having just rewatched Capaldi’s first season, in retrospect I think he cracked what he was going to to do pretty early, but everyone else needed to get Malcom Tucker out of their systems.)

Capaldi is also an excellent actor—probably the best to ever play the part—and also one who is very willing to not be the center of attention every scene, so he hands a lot of the spotlight off to his co-lead Louise Coleman’s Clara Oswald, which makes the show a lot better, but left him strangely blurry early on.

As such, I enjoyed it, but spent a lot of that first season asking “where are they going with this?” I was enjoying it, but it wasn’t clear what the take was. Was he… just kind of a jerk now? One of the running plot lines of the season was the Doctor wondering if he was a good man or not, which was a kind of weird question to be asking in the 51st year of the show. There was another sideplot where he didn’t get along with Clara’s new boyfriend which was also unclear what the point was. Finally, the previous episode ended with Clara and the Doctor having a giant argument that would normally be the kind of thing you’d do as a cast-member was leaving, but Coleman was staying for at least there rest of the year? Where was all this going?

For me, “Mummy” is where it all clicked: Capaldi’s take on the part, what the show was doing with Clara, the fact that their relationship was as toxic as it looked and that was the point.

There are so many great little moments in “Mummy”; from the basic premise of “there’s a mummy on the orient express… in space!”, to the “20s art deco in the future” design work to, the choice of song that the band is singing, to the Doctor pulling out a cigarette case and revealing that it’s full of jelly babies.

It was also the first episode of the year that had a straightforward antagonist, that the Doctor beat by being a little bit smarter and a little bit braver than everyone else. He’d been weirdly passive up to this point; or rather, the season had a string of stories where there wasn’t an actual “bad buy” to be defeated, and had more complex, ambiguous resolutions.

It’s the denouement where it really all landed for me. Once all the noise was over, the Doctor and Clara have a quite moment on an alien beach where he explains—or rather she realizes—what his plan had been all along and why he had been acting the way he had.

The previous episode had ended with the two of them having a tremendous fight, fundamentally a misunderstanding about responsibility. The Doctor had left Clara in charge of a decision that normally he’d have taken; Clara was angry that he’d left her in the lurch, he thought she deserved the right to make the decision.

The Doctor isn’t interested in responsibility—far from it, he’s one of the most responsibility-averse characters in all of fiction—but he’s old, and he’s wise, and he’s kind, and he’s not willing not to not help if he can. And so he’ll grudgingly take responsibility for a situation if that’s what it takes—but this version is old enough, and tired enough, that he’s not going to pretend to be nice while he does it.

He ends by muttering, as much to himself as to Clara, “Sometimes all you have are bad choices. But you still have to choose.”

And that’s this incarnation in a nutshell—of course he’d really rather be off having a good time, but he’s going to do his best to help where he can, and he isn’t going to stop trying to help just because all the options are bad ones. He’d really rather the Problem Trolly be going somewhere nice, but if someone has to choose which track to go down, he’ll make the choice.

“Mummy” is the middle of a triptych of episodes where Clara’s world view fundamentally changed. In the first, she was angry that the Doctor expected her to take responsibility for the people they came across, here in the second she realized why the Doctor did what he did, and then in the next she got to step in the Doctor’s shoes again, but this time understood.

The role of the “companion” has changed significantly over the years. Towards the end of the old show they realized that if the title character is an unchanging mostly-immortal, you can wrap an ongoing story around the sidekick. The new show landed on a model where the Doctor is mostly a fixed point, but each season tells a story about the companion changing, sometimes to the point where they don’t come back the next year.

Louise Coleman was on the show for two and a half seasons, and so the show did three distinct stories about Clara. The first two stories—“who is the impossible girl” and “will she leave the show to marry the boring math teacher”—turned out to be headfakes, red herrings, and actually the show was telling another story, hidden in plain sight.

The one story you can never tell in Doctor Who is why that particular Time Lord left home, stole a time capsule, and became “The Doctor”. You can edge up against it, nibble around the edges, imply the hell out of things, but you can’t ever actually tell that story. Except, what you can do is tell the story of how someone else did the same thing, what kind of person they had to be ahead of time, what kinds of things had to happen to them, what did they need to learn.

With “Mummy”, Clara’s fate was sealed—there was no going back to “real life”, or “getting married and settling down”, or even “just leaving”. The only options left were Apotheosis or Death—or, as it turns out, both, but in the other order. She had learned too much, and was on a collision course with her own stolen Tardis.

And standing there next to her was the aging punk space dad, passing though, trying to help. My Doctor.

---

Both Moffat’s time as show-runner and Capaldi’s time as the Doctor have been going through a much-deserved reappraisal lately. At the time, Capaldi got a weirdly rough reaction from online corners of the fanbase. Partly this was because of the aforementioned slow start, and partly because he broke the 21st century Who streak of casting handsome young men. But mostly this was because of a brew of toxic “fans”, bad-faith actors, and various “alt-right” grifters. (You know, Tumblr.) Because of course, this last August was also the 10th anniversary of “GamerGate”. How we ended up in a place that the unchained Id of the worst people alive crashed through video game and science fiction fandoms, tried to fix the Hugos, freaked out about The Last Jedi so hard it broke Hollywood, and then elected a racist game show host to be president is a topic for another time, but those people have mostly moved the grift on from science fiction—I mean, other than the Star Wars fanbase, which became a permanent host body.

The further we get from it, the more obvious what a grift it was. It’s hard to describe how how utterly deranged the Online Discourse^TM was. There was an entire cottage industry telling people not to watch Doctor Who because of the dumbest reasons imaginable in the late twenty-teens, and those folks are just… gone now, and their absense makes it even more obvious how spurious the “concerns” were. Because this was also the peak “taking bad-faith actors seriously” era. The general “fan” “consensus” was that Capaldi was a great actor let down by bad writing, in that sense of “bad” meaning “it wasn’t sexist enough for me.”

There’s a remarkable number of posts out there what’s left of the social web of people saying, essentially, “I never watched this because $YOUTUBER said it was bad, but this is amazing!” or “we never knew what we had until it was gone!”

Well, some of us knew.

I missed this back in November, but the official Doctor Who magazine did one of their rank every episode polls on the advent of the 60th anniversary. They do this every decade or so, and they’re always interesting, inasmuch as they’re a snapshot of the general fan consensus of the time. They’re not always a great view on how the general public sees this, I mean, a poll conducted by the official magazine is strongly self-selecting for Fans with a capital F.

I didn’t see it get officially posted anywhere, but most of the nerd news websites did a piece on it, for example: Doctor Who Fans Have Crowned the Best Episode – Do You Agree? | Den of Geek. The takeway is that the top two are Capaldis, and half of the top ten are Moffat’s. That would have been an unbelievable result a decade ago, because the grifters would have swamped the voting.

Then there’s this, which I’ve been meaning to link to for a while now. Over in the burned-out nazi bar where twitter used to be, a fan of Matt Smith’s via House of the Dragon found out that he used to be the lead of another science fiction show and started live tweeting her watch through Doctor Who: jeje (@daemonsmatt). She’s up through Capaldi’s second season now, as I type this, and it’s great. She loves it, and the whole thread of threads is just a river of positivity. And even in the “oops all nazis” version of twitter, no one is showing up in the comments with the same grifter crap we had to deal with originally, those people are just gone, moved on to new marks. It’s the best. It’s fun to see what we could have had at the time if we’d run those people off faster.

This all feels hopeful in a way that’s bigger than just people discovering my favorite version of my favorite show. Maybe, the fever is finally starting to break.

How to Monetize a Blog

If, like me, you have a blog thats purely a cost center, you may be interested in How to Monetize a Blog. Lotta good tips in there!

(Trust me, and make sure you scroll all the way to the end.)

Software Forestry 0x04: Library Upgrade Week

Here at Software Forestry we do occasionally try to solve problems instead of just turning them into lists of smaller problems, so we’re goona do a little mood pivot here and start talking about how to manage some of those forms of overgrowth we talked about last time.

First up: let me tell you the good news about Library Upgrade Week.

Just about any decently sized software system uses a variety of third party libraries. And why wouldn’t you? The multitude of high-quality libraries and frameworks out there is probably the best outcome of both the Open Source movement and Object-Oriented Software design. The specific mechanics vary between languages and their practitioner’s cultures, but the upshot is that very rarely does anyone build everything from scratch. There’s no need to go all historical reenactment and write your own XML parser.

Generally, people keep those libraries pinned and stay on one fixed version, rather than schlepping in a new version every-time an update happens. This is a good thing! Change is risk, and risk should be taken on intentionally. The downside is that those libraries keep moving forward, the version you’re using slips out of date, and now you have a bunch of Overgrowth. And so that means you need to upgrade them.

The upshot of all that is on a semi-regular basis, we all need to slurp in a bunch of new code no-one on the payroll wrote, and don’t really know how to test. Un-Reviewed Code Is Tech Debt, and one of the mantras of writing good tests is “don’t test the framework”, so this is always a little iffy.

It’s incredibly easy to just keep letting those weeds grow a little longer. “The new version doesn’t have anything we need”, “there’s no bugs”, “if it ain’t broke don’t fix it”, and so on. They always take too long, don't usually deliver immediate gratification, and are hard to schedule. It’s no fun, and no one likes to do it.

The trick is to turn it into a party.

It works like this: set aside the last week of the quarter to concentrate on 3rd party library upgrades. Regardless of what your formal planning cycle or process is, most businesses tends to operate on quarters, and there’s usually a little dead time at the end of the quarter you can repurpose.

The Process:

1. Form squads. Each squad is a group of like-minded individuals focused on a single 3rd party library or framework. Squads are encouraged to be cross-team. Each squad will focus on updating that 3rd party library in all applications or places where it is used. The intent is to make this a group event, where people can help each other out. Participation is not mandatory.

2. Share squad membership and goals ahead of time. Leadership should reserve the right to veto libraries as “too scary” or “not scary enough”. Libraries with a high severity alerts or known CVE are good candidates.

3. That week, each squad self organizes and works as a group through any issues caused by the upgrade. Other than major outages or incidents, squad members should be excused from other “run the business” type work for that week; or rather, the library upgrades are “the business.” Have fun!

4. On that Friday hold the Library Upgrade Week Show-n-Tell. Every team should demo what they did, how they did it, and what it took to pull it off. Tell war stories, hold a happy hour, swap jokes. If a squad doesn’t finish that's okay! The expectation is that they’ll have learned a lot about what it'll take to finish, and that work will be captured in the relevant team’s todo lists. If you’re in a process with short develop-deploy increments (like sprints) you can make the library upgrade(s) a release on its own. Ideally you already have a way to sign off a release as not containing regressions, and so a short release with just a library upgrade is a great way to make sure you didn’t knock some dominos over.

But wait! There's more! All participants will vote on awards to give to squads, for things like:

• Error message with least hits on Stack Overflow
• Largest version number jump
• Most lines changed
• Fewest lines changed
• Best team name
• Best presentation

Go nuts! Have a great time!

🌲

Yes, it’s a little silly, but that’s the point. I’ve deployed a version of this at a couple of jobs now, and it’s remarkable how effective it is. The first couple of cycles people hit the “easy” ones—uprev the logging library or a JSON parser or something. But then, once people know that Library Upgrade Week is coming, they start thinking about the harder stuff, and you start getting people saying they want to take a swing at the main framework, or the main language version, or something else load-bearing. It’s remarkable how much progress two or three people can make on a problem that looks unsolvable when they have an uninterrupted week to chew on it. (If you genuinely can’t spare a handful of folks to do some weeding four weeks out the the year, that’s a much larger problem than out of date libraries, and you should go solve that problem first. Like, right now.)

There’s an instinct to take the core idea to schedule this kind of maintenance for a few times a year, but leave off the part where it’s a party. This is a mistake. This is work people want to do even less than their usual work; the trick is to make everthing around it fun.

We’re Foresters, and both we and the Forest are here long term. The long term health of both depends on the care of the Forest being something that the Foresters enjoy, and it’s okay to stack that deck in your favor.

Wacky Times for AI

Been a wacky month or two for AI news! Open AI is reorganizing! Apple declined to invest! Whatsisname decided he wanted equity after all! The Governor of CA vetoed an AI safety bill! Microsoft is rebooting Three Mile Island, which feels like a particularly lazy piece of satire from the late 90s that escaped into reality! Study after study keeps showing no measurable benefit to AI deployment! The web is drowning in AI slop that no one likes!

I don’t know what any of that means, but it’s starting to feel like we’re getting real close to the part of The Sting where Kid Twist tells Quint from Jaws something confusing on purpose.

But, in our quest here at Icecano to bring you the best sentences from around the web, I’d like to point you at The Subprime AI Crisis because it includes this truly excellent sentence:

Generative AI must seem kind of magical when your entire life is either being in a meeting or reading an email

Oh Snap!

Elsewhere in that piece it covers the absolutely eye-watering amounts of money being spent on the plagiarism machine. There are bigger problems than the cost; the slop itself, the degraded information environment, the toll on the actual environment. But man, that is a hell of a lot of money to just set on fire to get a bunch of bad pictures no one likes. The opportunity cost is hard to fathom; imagine what that money could have been spent on! Imagine how many actually cool startups that would have launched! Imagine how much real art that would have bought!

But that’s actually not what I’m interested in today, what I am interested in are statements like these:

State of Play: Kobold Press Issues the No AI Pledge

Legendary Mario creator on AI: Nintendo is “going the opposite direction”

I stand by my metaphor that AI is like asbestos, but increasingly it’s also the digital equivalent of High Fructose Corn Syrup. Everyone has accepted that AI stuff is “not as good”, and it’s increasingly treated as low-quality filler, even by the people who are pushing it.

What’s intriguing to me is that companies whose reputation or brand centers around creativity or uniqueness are working hard to openly distance themselves. There’s a real “organic farm” energy, or maybe more of a “restaurant with real food, not fast food.”

Beyond the moral & ethical angle, it gives me hope that “NO AI” is emerging as a viable advertising strategy, in a way that “Made with AI” absolutely isn’t.

Dungeons & Dragons (2024): Trying to Make a Big Tent Bigger

Dungeons & Dragons is a weird game. I don’t mean that as some kind of poetic statement about role-playing games in general, I mean that specifically within the world of tabletop RPGs, D&D is weird. It’s weird for a lot of reasons, including, but not limited to:

1. It’s the only TTRPG with with actual “real world” name recognition or any sort of cross-over brand awareness.
2. For most of its existence, it hasn’t been a very good game.

And then for bonus points, it’s not even one game! Depending on how you count it’s at least six different related but totally incompatible games.

The usual example for a brand name getting turned into a generic noun is “kleenex”, but the thing where “Dungeons and Dragons” has become a generic noun for all RPGs is so strange.

It’s so much more well known that everything else it’s like if all TV shows were called MASH, as in “hey, that new MASH with the dragons is pretty good, ” or “I stayed in and rewatched that MASH with the time-traveller with the police box,” etc.

There was a joke in the mid-90s that all computer games got pitched as “it’s like DOOM, but…” and then just pitched the game regardless of how much it was actually like Doom; “It’s like DOOM except it’s not in first person, it’s not in real time, you don’t have a gun, you’re a pirate, you’re not in space, and instead you solve puzzles”. D&D is like that but for real.

Which is a testament to the power of a great name and the first mover advantage, because mechanically, the first 30-or-so years of the game were a total mess. In a lot of ways, RPGs became an industry because everyone who spent more than about 90 seconds with D&D in the 70s, 80, or 90s immediately thought of ten ways to improve the game, and were right about at least eight of them. (One of the best running bits in Shannon Applecline’s seminial Designers & Dungeons is how many successful RPG companies literally started like this.)

And this mechanical weirdness isn’t just because it was first, but because of things like Gary Gygax’s desire to turn it into a competitive sport played at conventions, but also make sure that Dave Arneson didn’t get paid any royalties, and also show off how many different names of polearms he knew. As much as RPGs are sold as “do anything, the only limit is your imagination!” D&D has always been defined by it’s weird and seemingly arbitrary limits. So there’s a certain semi-effable “D&D-ness” you need for a game to be “Dungeons & Dragons” and not just another heroic fantasy game, not all of which make for a great system. It’s a game where its flaws have become part of the charm; the magic system is objectively terrible, but is also a fundamental part of it’s D&D-ness.

The upshot of all that is that for most of its life, D&D had a very clear job within the broader TTRPG world: it was the game that onboarded new players to the hobby, who then immediately graduated to other, better games. The old Red Box was one of the great New Customer Acquisition products of all time, but most people proceeded to bounce right off Advanced D&D, and then moved on to Ninja Turtles, or Traveller, or Vampire, or GURPS, or Shadowrun, or Paranoia, or Star Wars, or any number of other systems that were both better games and were more tailored to a specific vibe or genre, but all assumed you already knew how to play. It wasn’t a game you stuck with. You hear stories about people who have been playing the same AD&D 2nd Edition game for years, and then you ask a couple of follow-up questions and realize that their home rules make the Ship of Theseus look under-remodeled.

Now, for the hobby at large that’s fairly healthy, but if your salary depends on people buying “Dungeons & Dragons” books specifically, I can see how that would be fairly maddening. The game, and the people who make it, have been in an ongoing negotiation with the player base to find a flavor of the game that people are actually willing to stick around for. This results in the game’s deeply weird approach to “Editons”, where each numbered edition is effectively a whole new game, always sold with a fairly explicit “Look! We finally fixed it!”

This has obviously been something of a mixed bag. I think a big part of the reason the d20 boom happened at the turn of the century was that for the first time, 3rd edition D&D was actually a good game. Not perfect, but finally worth playing. 4e, meanwhile, was the best-designed game that no one wanted to play, and it blew up the hobby so much that it created both Pathfinder and served as one of the sparks to light off the twenty-teens narrative RPG boom.

Another result of this ongoing negotiation is that D&D also has a long tradition of “stealth” updates, where new books come out that aren’t a formal revision, but if you pull the content in it dramatically changes the game. AD&D 1 had Oriental Adventures and Unearthed Arcana, AD&D 2 had those Player’s Option books (non-weapon proficiencies!), Basic had at least three versions (the original B/X, the BECMI sets, and then the Rules Cyclopedia). 3rd had the rare Formal Update in the form of the 3.5 release, but it also had things like the Miniatures Handbook (which, if you combine that with the SAGA Edition of Star Wars, makes the path from 3 to 4 more obvious.) 4e had Essentials.

2024 is a radically different time for tabletop games than 2014 was. As the twenty-teens dawned, there was growing sense that maybe there just wasn’t going to be a commercial TTRPG industry anymore. Sales were down, the remaining publishers were pivoting to PDF-only releases, companies were either folding or moving towards other fields. TTRPGs were just going to be a hobbyist niche thing from here on out, and maybe that was going to be okay. I mean, text-based Interactive Fiction Adventure games hadn’t been commercially viable since the late 80s, but the Spring Thing was always full of new submissions. I remember an article on EN World or some such in 2012 or 2013 that described the previous year’s sales as “an extinction level event for the industry.”

Designers & Dungeons perfectly preserves the mood from the time. I have the expanded 2014 4-volume edition, although the vast majority of the content is still from the 2011 original, which officially covers the industry up to 2009 and then peeks around the corner just a bit. The sense of “history being over” pervades the entire work, theres a real sense that the heyday is over, and so now is the time to get the first draft of history right.

As such, the Dungeons & Dragons (2014) books had a certain “last party of summer vacation” quality to them. The time where D&D would have multiple teams with cool codenames working on different parts of the game was long past, this was done by a small group in a short amount of time, and somewhat infamously wasn’t really finished, which is why so many parts of the book seem to run out of steam and end with a shrug emoji and “let the DM sort it out.” The bones are pretty good, but huge chunks of it read like one of those book reports where you’re trying to hide the fact you only read the first and last chapters.

That’s attracted a lot of criticism over the years, but in their (mild) defense, I don’t think it occurred to them that anyone new was going to be playing Fifth. “We’re gonna go out on a high note, then turn the lights out after us.” Most of the non-core book product line was outsourced for the first year or so, it was all just sorta spinning down.

Obviously, that’s not how things went. Everyone has their own theory about why 5th Edition caught fire the way no previous edition had, and here’s mine: The game went back to a non-miniatures, low-math design right as the key enabling technology for onboarding new players arrived: Live Play Podcasts. By hook or by crook, the ruleset for 5E is almost perfect for an audio-only medium, and moves fast, in a way that none of the previous 21st century variants had been.

And so we find outselves in a future where D&D, as a brand, is one of Hasbro’s biggest moneymakers.

Part of what drove that success is that Hasbro has been very conservative about changes to the game, which has clearly let the game flourish like never before, but the same issues are still there. Occasionally one of the original team would pop up on twitter and say something like “yeah, it’s obvious now what we should have done instead of bonus actions,” but nothing ever shipped as a product.

5th edition has already had its stealth update in the form the Tasha/Xanathar/Mordenkainen triptych, but now we’ve got something that D&D really hasn’t had before: the 2024 books are essentially 5th Edition, 2nd Edition. Leading the charge of a strangely spaced-out release schedule is the new Player’s Handbook (2024).

Let’s start with the best part: The first thirty pages are a wonder. It opens with the best “what is an RPG” intro I have ever read, and works its way up though the basics, and by page 28 has fully explained the entire ruleset. To be clear: there aren’t later chapters with names like “Using Skills” or “Combat”, or “Advanced Rules”, this is it.

The “examples of play” are a real thing of art. The page is split into two columns: the left side of the page is a running script-like dialogue of play, and the right side is a series of annotations and explanations describing exactly what rule was in play, why they rolled what they rolled, what the outcome was. I’ve never seen anything quite like it.

This is followed by an incredibly clear set of instructions on how to create a character, and then… the rest of the book is reference material. Chapters on the classes, character origins, feats, equipment, spells, a map of the Planes, stat blocks for creatures to use as familiars or morph targets.

Finally, the book ends with its other best idea: the Rules Glossary. It’s 18 pages of The Rules, alphabetical by Formal Name, clearly written. Theres no flipping around in the book looking for how to Grapple or something, it’s in the glossary. Generally, the book will refer the reader to the glossary instead of stating a rule in place.

It’s really easy to imagine how to repackage this layout into a couple of Red Box–style booklets covering the first few levels. You can basically pop the first 30 pages out as-is and slap a cover on it that says “Read This First!”

Back when I wrote about Tales of the Valiant, I made a crack that maybe there just wasn’t a best order for this material. I stand corrected. It’s outstanding.

Design-wise the book is very similar to it’s predecessor: same fonts, same pseudo-parchment look to the paper, same basic page layout. My favorite change is that the fonts are all larger, which my rapidly aging eyes appreciates.

It’s about 70 pages longer than the 2014 book, and it wouldn’t surprise me to learn that both books have the same number of words and that the extra space is taken up with the larger text and more art. The book is gorgeous, and is absolutely chock full of illustrations. Each class gets a full-page piece, and then each subclass gets a half-page piece showing an example of that build. It’s probably the first version of this game where you can flip through the classes chapter, and then stop at a cool picture and go “hang on, I want to play one of THOSE”. The art style feels fresh and modern in a way that’s guaranteed to make everyone say “that is so twenties” years from now; the same way that the art for the original 3rd edition books looked all clean and modern at the time, but now screams “late 90s” in a way I don’t have the critical vocabulary to describe. (Remember how everything cool had to be asymmetrical for a while there? Good times!)

Some of the early art previewed included a piece with the cast from 80s D&D cartoon drawn in the modern style of the book. At the time, I thought that was a weird piece of nostalgia bait: really? Now’s the time to do a callback to a 40-year old cartoon? Whose the audience for that?

But I was wrong about the intent, because this book is absolutely full of all manner of callbacks and cameos. The DragonLance twins are in the first couple of pages, everyone’s favorite Drow shows up not long after, there’s a guy from Baldur’s Gate 3, the examples of play are set in Castle Ravenloft, there’s Eberron airships, characters from the 80s action figure line, the idol from the old DMG cover, a cityscape of Sigil with the Lady floating down the street. It’s not a nostalgia play so much as it is a “big tent” play: the message, over and over again, is that everything fits. You remember some weird piece of D&D stuff from ages ago? Yeah, that’s in here too. Previous versions of this game have tended to start with a posture of “here’s the default way to play now”, with other “weirder” stuff floating in later. This takes the exact opposite approach, this is full-throated “yes, and” to everything D&D. So not only does Spelljammer get a shoutout in the 2 page appendix about the planes, but rules for guns are in the main equipment chapter, the psionic subclasses are in the main book, airships are in the travel costs table. Heck, the para-elemental planes are in the inner planes diagram, and I thought I was the only person who remembered those existed.

And this doesn’t just mean obscure lore pulls, the art is a case study in how to do “actual diversity”. There’s an explosion of body types, genders, skin tones, styles, and everyone looks cool.

Theres a constant, pervasive sense of trying to make the tent as big and as welcoming as possible. Turns out “One D&D” was the right codename for this; it wasn’t a version number, it was a goal.

Beyond just the art, 2024 book has a different vibe. There’s a whimsicalness from the 2014 version that’s gone: the humorous disclaimer on the title page isn’t there, there isn’t a joke entry for THAC0 in the index. If the 2014 book was an end-of-summer party, this is a start of the year syllabus.

The whole thing has been adjusted to be easier to use. The 2014 book had a very distinct yellowed-parchment pattern behind the text, the 2024 book has a similar pattern, but it’s much less busy and paler, so the text stands out better against the background. All the text is shorter, more to the point. The 2014 book had a lot of fluff that just kinda clogged up the rules when you were trying to look something up in a hurry, the 2024 book has been through an intense editing pass.

As an example: in the section for each class, each class ability has a subheading with the name of the power, and then a description, like this:

Invert the Polarity Starting at 7th level, your growing knowledge of power systems allows you to invert the polarity of control circuits, such as in teleport control panels or force fields. As a bonus action, you can add a d4 to attempts to control electrical systems. After using this power, you must take a short or long rest before using it again.

Now, it’s like this:

Level 7: Invert the Polarity Add 1d4 to checks made with the Sonic Screwdriver Tool. You regain this feature after a short or long rest.

For better or worse, it’s still 5th edition D&D. All the mechanical warts of the system are still there; the weird economy around Bonus Actions, too many classes have weird pools of bonus dice, the strange way that some classes get a whole set of “spell-like” powers to choose from, and other classes “just get spells.” There still isn’t a caster that just uses spell points. Warlocks still look like they were designed on the bus on the way to school the morning the homework was due. Inspiration is still an anemic version of better ideas from other systems. Bounded accuracy still feels weird if you’re not used to it. It’s still allergic to putting math in the text. It still tries to sweep more complex mechanics under the rug by having a very simple general rule, and then a whole host of seemingly one-off exceptions that feel like could have just been one equation or table. The text is still full of tangled sentences about powers recharging after short and long rests instead of just saying powers can used used so many times per day or encounter. There’s still no mechanic for “partial success” or “success with consequences.” You still can’t build any character from The Princess Bride. If 5th wasn’t your jam, there’s nothing here that’ll change your mind.

On the other hand, the good stuff is largely left unchanged: The Advantage/Disadvantage mechanic is still brilliant. The universal proficiency bonus is still a great approach. Bounded Accuracy enables the game to stay fun long past the point where other editions crash into a ditch filled with endless +2 modifiers. It’s the same goofball combat-focused fantasy-themed superhero game it’s been for a long time. I’ve said many times, 5e felt like the first version of D&D that wasn’t actively fighting against the way I like to run games, and the 2024 version stays that way.

All that said, it feels finished in a way the 2014 book didn’t. It’s a significantly smaller mechanical change that 3 to 3.5 was, but the revisions are where it counts.

Hasbro has helpfully published a comprehensive list of the mechanics changes as Updates in the Player’s Handbook (2024) | Dungeons & Dragons, so rather than drain the list, here are the highlights that stood out to me:

The big one is that Races are now Species, and Backgrounds have been reworked and made more important, and the pair are treated as “Origins”. This is massive improvement, gone is the weird racial determinism, and where you grew up is now way more important than where your ancestors came from. There’s some really solid rules for porting an older race or background into the new rules. The half-races are gone, replaced by “real Orcs” and the Aaisimar and Goliaths being called up to the big leagues. Backgrounds in 2014 were kinda just there, a way to pick up a bonus skill proficiency, here they’re the source of the attribute bonus and an actual Feat. Choosing a pair feels like making actual choices about a specific character in a different way that how previous editions would sort of devolve that choice into “choose your favorite Fellowship member”.

Multi-classing and Feats are flushed out and no longer relegated to an “optional because we ran out of time” sidebar. Feats specifically are much closer to where they were in 3e—interesting choices to dial in your character. The they split the difference with the choice you had to make in 5e to either get a stat boost or a feat, you still make that choice, but the stat boost bumps up two stats, and every general feat inclues a single stat boost.

The rules around skills vs tools make sense. At first glance, there don’t seem to be weird overlaps anymore. Tools were one of those undercooked features in 2014, they were kinda like skills, but not? When did you use a tool vs a plain skill check? How do you know what attribute bonus to use? Now, every attribute and skill has a broad description and examples of what you can use them from. Each tool has a full description, including the linked attribute, at least one action you can use it for, and at least one thing you can craft with it. And, each background comes with at least one tool proficiency. You don’t have to guess or make something up on the fly, or worse, remember what you made up last time. It’s not a huge change, but feels done.

Every class has four subclasses in the main book now, which cover a pretty wide spread of options, and sanity has prevailed and all subclasses start at level 3. (In a lot of ways, level 3 is clearly the first “real” level, with the first two as essentially the tutorial, which syncs well with that if you follow the recommended progression, you’ll hit 3rd level at the end of the second session.)

The subclasses are a mix of ones from the 2014 book, various expansions, and new material, but each has gotten a tune up top focus on what the actual fantasy is. To use Monk for example, the subclasses are “Hong Kong movie martial artist”, “ninja assassin”, “airbender”, and, basically, Jet Li from Kiss of the Dragon? The Fighter subclasses have a pretty clear sliding scale of “how complicated do you want to make this for yourself,” spanning “Basic Fighter”, “3rd Edition Fighter”, “Elf from Basic D&D”, and “Psionics Bullshit (Complementary)”.

Weapons now have “Weapon Mastery Properties” that, if you have the right class power or feat, allow you do do additional actions or effects with certain weapons, which does a lot to distinguish A-track fighters from everyone else without just making their attack bonus higher.

The anemic Ideals/Flaws/Bonds thing from 2014 is gone, but in it’s place there’s a really neat set of tables with descriptive words for both high and low attributes and alignment that you can roll against to rough in a personality.

On the other hand, lets talk about whats not here. The last page of the book is not the OGL, and there’s no hint of what any future 3rd party licensing might be. The OGL kerfluffle may have put the 2014 SRD under a CC license, but there’s no indication that there will even be a 2024 SRD.

There’s basically nothing in the way of explicit roleplaying/social hooks; and nothing at all in the way of inter-party hooks. PbtA is a thing, you know? But more to the point, so was Vampire. So was Planescape. There’s a whole stack of 30-year old innovations that just aren’t here.

Similarly there’s no recognition of “the party” as a mechanical construct.

There’s nothing on safety tools or the like; there is a callout box about Session Zero, but not much else. I’m withholding judgement on that one, since it looks like there’s something on that front in the DMG.

There’s very little mechanics for things other than combat; although once again, D&D tends to treat that as a DMG concern.

The other best idea that 4e had was recognizing that “an encounter” was a mechanical construct, but didn’t always have to mean “a fight.” This wasn’t new there, using games I can see from where I’m sitting as an example, Feng Shui was organized around “scenes” in the early 90s. Once you admit an encounter is A Thing, you can just say “this works once an encounter” without having to put on a big show about short rests or whatever, when everyone knows what you mean.

Speaking for myself, as someone who DMs more than he plays, I can’t say as I noticed anything that would change the way I run. The ergonomics and presentation of the book, yes, more different and better player options, yes, but from the other side of the table, they’re pretty much the same game.

Dungeons & Dragons is in a strage spot in the conceptual space. It’s not an explicit generic system like GURPS or Cypher, but it wants to make the Heroic Fantasy tent big enough that it can support pretty much any paperback you find in the fantasy section of the used book store. There’s always been a core of fantasy that D&D was “pretty good at” that got steadily weedier the further you got from it. This incarnation seems to have done a decent job of widening out that center while keeping the weed growth the a minimum.

It seems safe to call this the best version of Dungeons & Dragons to date, and perfectly positioned to do the thing D&D is best at: bring new players into the hobby, get them excited, and then let them move on.

But, of course, it’s double volcano summer, so this is the second revised Fifth Edition this year, after Kobold’s Tales of the Valiant. Alert readers will note that both games made almost the exact same list of changes, but this is less “two asteroid movies” and more “these were the obvious things to go fix.” It’s fascinating how similar they both are, I was expecting to have a whole compare and contrast section here, but not so much! I’m not as tapped into “the scene” as I used to be, so I don’t know how common these ideas were out in the wild, but both books feel like the stable versions of two very similar sets of house rules. It kinda feels like there are going to be a lot of games running a hacked combo of the the two.

(To scratch the compare-and-contrast itch: At first glance, I like the ToV Lineage-Heritage-Background set more than the D&D(2024) Species-Background pair, but the D&D(2024) weapon properties and feats look better than their ToV equivalents. Oh, to be 20 and unemployed again!)

The major difference is that ToV is trying to be a complete game, whereas the 2024 D&D still wants to treat the rest of the post-2014 product line as valid.

As of this writing, both games still have their respective DM books pending, which I suspect is where they’ll really diverge.

More than anything, this reminds me of that 2002-2003 period where people kept knocking out alternate versions of 3e (Arcana Unearthed, Conan, Spycraft, d20 Star Wars, etc, etc) capped off with 3.5. A whole explosion of takes on the same basic frame.

This feels like the point where I should make some kind of recommendation. Should you get it?That feels like one of those “no ethical consumption under capitalism” riddles. Maybe?

To put it mildly, it hasn’t been a bump-free decade for ‘ol Hasbro; recently the D&D group has made a series of what we might politely call “unforced errors,” or if we were less polite “a disastrously mishandled situation or undertaking.”

Most of those didn’t look malevolent, but the sort of profound screwups you get when too many people in the room are middle-aged white guys with MBAs, and not enough literally anyone else. Credit where credit is due, and uncharacteristically for a public-traded American corporation, they seemed to actually be humbled by some of these, and seemed to be making a genuine attempt to fix the systems that got them into a place where they published a book where they updated an existing race of space apes by giving them the exciting new backstory of “they’re escaped slaves!” Or blowing up the entire 3rd party licensing model for no obvious reason. Or sending the literal Pinkertons to someone’s house.

There seems to be an attempt to use the 2024 books to reset. There seems to be a genuine attempt here to get better at diversity and inclusion, to actually move forward. On the other hand, there’s still no sign of what’s going to happen next with the licensing situation.

And this is all slightly fatuous, because I clearly bought it, and money you spend while holding your nose is still legal tender. Your milage may vary.

My honest answer is that if you’re only looking to get one new 5e-compatible PHB this year, I’d recommend you get Tales of the Valiant instead, they’re a small company and could use the sales. If you’re in the market for a second, pick this one up. If you’ve bought in to the 5e ecosystem, the new PHB is probably worth the cover price for the improved ergonomics alone.

Going all the way back to where we started, the last way that D&D is weird is that whether we play it or not, all of us who care about this hobby have a vested interest in Dungeons & Dragons doing well. As D&D goes, so goes the industry: if you’ll forgive a mixed metaphor, when D&D does well the rising tide lifts all boats, but when it does poorly D&D is the Fisher King looking out across a blasted landscape.

If nothing else, I want to live in a world where as many people’s jobs are “RPG” as possible.

D&D is healthier than it’s ever been, and that should give us all a sigh of relief. They didn’t burn the house down and start over, they tried to make a good game better. They’re trying to make it more welcoming, more open, trying to make a big tent bigger. Here in the ongoing Disaster of the Twenties, and as the omni-crisis of 2024 shrieks towards its uncertain conclusion, I’ll welcome anyone trying to make things better.

Software Forestry 0x03: Overgrowth, Catalogued

Previously, we talked about What We Talk About When We Talk About Tech Debt, and that one of the things that makes that debt metaphor challenging is that it has expanded to encompass all manner of Overgrowth, not all of which fits that financial mental model.

From a Forestry perspective, not all the things that have been absorbed by “debt” are necessarily bad, and aren’t always avoidable. Taking a long-term, stewardship-focused view, there’s a bunch of stuff that’s more like emergent properties of a long-running project, as opposed to getting spendy with the credit card.

So, if not debt, what are we talking about when we talk about tech debt?

It’s easy to get over-excited about Lists of Things, but I got into computer science from the applied philosophy side, rather than the applied math side. I think there are maybe seven categories of “Overgrowth” that are different enough to make it useful to talk about them separately:

1. Actual Tech Debt.

Situations where an explicit decision to do something “not as good” to ship faster. There’s two broad subcategories here: using a hacky or unsustainable design to move faster, and cutting scope to hit a date.

In fairness, the original Martin Fowler post just talks about “cruft” in a broad sense, but generally speaking “Formal” (orthodox?) tech debt assumes a conscious choice to accept that debt.

This is the category where the debt analogy works the best. “I can’t buy this now with cash on hand, but I can take on more credit.” (Of course, this also includes “wait, what’s a variable rate?”)

In my experience, this is the least common species of Overgrowth, and the most straightforwardly self correcting. All development processes have some kind of “things to do next” list or backlog, regardless of the formal name. When making that decision to take on the debt, you put an item on the todo list to pay it off.

That list of cut features becomes the nucleus of the plan for the next major version, or update, or DLC. Sometimes, the schedule did you a favor, you realize it was a bad idea, and that cut feature debt gets written off instead of paid off.

The more internal or infrastructure–type items become those items you talk about with the phrase “we gotta do something about…”; the logging system, the metrics observability, that validation system, adding internationalization. Sometimes this isn’t a big formal effort, just a recognition that the next piece of work in that area is going to take a couple extra days to tidy up the mess we left last time.

Fundamentally, paying this off is a scheduling and planning problem, not a technical one. You had to have some kind of an idea about what the work was to make the decision to defer the work, so you can use that same understanding to find it a spot on the schedule.

That makes this the only category where you can actually pay it off. There’s a bounded amount of work you can plan around. If the work keeps getting deferred, or rescheduled, or kicked down the road, you need to stop and ask yourself if this is actually debt or a something asperational that went septic on you.

2. We made the right decision, but then things happened.

Sometimes you make the right decisions, don’t choose to take on any debt, and then things happen and the world imposes work on you anyway.

The classic example: Third party libraries move forward, the new version isn’t cleanly backwards compatible, and the version you’re using suddenly has a critical security flaw. This isn’t tech debt, you didn’t take out a loan! This is more like tech property taxes.

This is also a planning problem, but tricker, because it’s on someone else’s schedule. Unlike the tech debt above, this isn’t something you can pay down once. Those libraries or frameworks are going to keep getting updated, and you need to find a way to stay on top of them without making it a huge effort every time.

Of course, if they stop getting updated you don’t have an ongoing scheduling problem anymore, but you have the next category…

3. It seemed like a good idea at the time.

Sometimes you just guess wrong, and the rest of the world zigs instead of zags. You do your research, weigh the pros and cons, build what you think is the right thing, and then it’s suddenly a few years later and your CEO is asking why your best-in-class data rich web UI console won’t load on his new iPad, and you have to tell him it’s because it was written in Flash.

You can’t always guess right, and sometimes you’re left with something unsupported and with no future. This is very common; there’s a whole lot of systems out there that went all-in on XML-RPC, or RMI, or GWT, or Angular 1, or Delphi, or ColdFusion, or something else that looked like it was going to be the future right up until it wasn’t.

Personally, I find this to be the most irritating. Like Han Solo would say, it’s not your fault! This was all fine, and then someone you never met makes a strategic decision, and now you have to decide how or if you’re going to replace the discontinued tech. It’s really easy to get into a “if it ain’t broke don’t fix it” headspace, right up until you grind to a halt because you can’t hire anyone who knows how to add a new screen to the app anymore. This is when you start using phrases like “modernization effort”.

4. We did the best we could but there are better options now.

There’s a lot more stuff available than there used to be, and so sometimes you roll onto a new project and discover a home-brew ORM, or a hand-rolled messaging queue, or a strange pattern, and you stop and realize that oh wait, this was written before “the thing I would use” existed. (My favorite example of this is when you find a class full of static final constants in an old Java codebase and realize this was from before Java 5 added enums.)

A lot of the time, the custom, hand-rolled thing isn’t necessarily “worse” than some more recent library or framework, but you have to have some serious conversations about where to spend your time; if something isn’t your core business and has become a commodity, it’s probably not worth pouring more effort in to maintaining your custom version. Everyone wants to build the framework, but no one really wants to maintain the framework. Is our custom JSON serializer really still worth putting effort into?

Like the previous, it’s probably time to take a deep breath and talk about re-designing; but unlike the previous, the persion who designed the current version is probably still on the payroll. This usually isn’t a technical problem so much as it is a grief management one.

5. We solved a different problem.

Things change. You built the right thing at the time, but now we got new customers, shifted markets, increased scale, maybe the feds passed a law. The business requirements have changed. Yesterday, this was the right thing, and now it isn’t.

For example: Maybe you had a perfectly functional app to sell mp3 files to customers to download and play on their laptops, and now you have to retrofit that into a subscription-based music streaming platform for smartphones.

This is a good problem to have! But you still gotta find a way to re-landscape that forest.

6. Context Drift.

There’s a pithy line that Legacy Code is “code without tests,” but I think that’s only part of the problem. Legacy code is code without continuity of philosophy. Why was it built this way? There’s no one left who knows! A system gets built in a certain context, and as time passes that context changes, and the further away we get from the original context, the more overgrown and weedy the system appears to become. Tests—good tests—are one way to preserve context, but not the only way.

A whole lot of what’s called “cruft” is here, because It’s harder to read code than to write it.. A lot of that “cruft” is congealed knowledge. That weird custom string utility thats only used the one place? Sure, maybe someone didn’t understand the standard library, or maybe you don’t know about the weekend the client API started handing back malformed data and they wouldn’t fix it—and even worse, this still happens at unpredictable times.

This is both the easiest and least glamorous to treat, because the trick here is documentation. Don’t just document what the code does, document why the code does what it does, why it was built this way. A very small amount of effort while something is being planted goes a long way towards making sure the context is preserved. As Henry Jones Sr, says, you write it down so you don’t have to remember.

To put all that another way: Documentation debt is still tech debt.

7. Not debt, just an old mistake.

The one no one likes to talk about. For whatever reason, someone didn’t do A-quality work. This isn’t necessarily because they were incompetent or careless, sometimes shit happens, you know? This the flip side of the original Tech Debt category; it wasn’t on purpose, but sometimes people are in a hurry, or need to leave early, or just can’t think of anything better.

And so for whatever the reason, the doors aren’t straight, there’a bunch of unpainted plywood, those stairs aren’t up to code. Weeds everywhere. You gotta spend some time re-cutting your trails through the forest.

🌲

As we said at the start, each of those types of Overgrowth has their own root causes, but also needs a different kind of forest management. Next week, we start talking about techniques to keep the Overgrowth under control.

TV Rewatch: The Good Place

spoilers ahoy

We’ve been rewatching The Good Place. (Or rather, I’ve been rewatching it—I watched it on and off while it was on—everyone else around here is watching it for the first time.)

It is, of course, an absolute jewel. Probably the last great network comedy prior to the streaming/covid era. It’s a masterclass. In joke construction, in structure, in hiding jokes in set-dressing signs. It hits that sweet spot of being both genuinely funny while also have recognizable human emotions, which tends to beyond the grasp of most network sitcoms.

It’s also a case study in why you hire people with experience; Kristen Bell and Ted Danson are just outstanding at the basic skill of “starring in a TV comedy”, but have never as good as they are here. Ted Danson especially is a revelation here, he’s has been on TV essentially my entire life, and he’s better than he’s ever been, but in a way that feels like this is because he finally has material good enough.

But on top of all that, It’s got a really interesting take on what being a “good person” means, and the implications thereof. It’s not just re-heated half-remembered psychology classes, this is a show made by people that have really thought about it. Philosophers get named-dropped, but in a way that indicates that the people writing the show have actually read the material and absorbed it, instead of just leaving a blank spot in the script that said TECH.

Continuing with that contrasting example, Star Trek: The Next Generation spent hours on hours talking about emotions and ethics and morality, but never had an actual take on the concept, beyond a sort of mealy-mouthed “emotions are probably good, unless they’re bad?” and never once managed to be as insightful as the average joke in TGP. It’s great.

I’m gonna put a horizontal line here and then do some medium spoilers, so if you never watched the show you should go do something about that instead of reading on.

---

...

The Good Place has maybe my all-time favorite piece of narrative sleight of hand. (Other than the season of Doctor Who that locked into place around the Tardis being all four parts of “something old, something new, something borrowed, something blue.”)

In the very first episode, a character tells something to another character—and by extension the audience. That thing is, in fact, a lie, but neither the character nor the audience have any reason to doubt it. The show then spends the rest of the first season absolutely screaming at the audience that this was a lie, all while trusting that the audience won’t believe their lying eyes and ignore the mounting evidence.

So, when the shoe finally drops, it manages to be both a) a total surprise, but also b) obviously true. I can’t think of another example of a show that so clearly gives the audience everything they need to know, but trusts them not to put the pieces together until the characters do.

And then, it came back for another season knowing that the audience was in on “the secret” and managed to both be a totally new show and the same show it always was at the same time. It’s a remarkable piece of work.

Checking In On Space Glasses

It’s been a while since we checked in on Space Glasses here at the old ‘cano, and while we weren’t paying attention this happens: Meta Unveils 'Orion' Augmented Reality Glasses.

Most of the discussion—rightly—has focused on the fact that they’re a non-production internal prototype that reportedly costs 10 Gs a pop. And they’re a little, cough, “rubenesque”?

Alert readers will recall I spent several years working on Space Glasses professionally, trying to help make fetch happen as it were, and I looked at a lot of prototype or near-prototype space glasses. These Orion glasses were the first time I sat up and said “ooh, they might be on to something, there.”

My favorite piece about the Orions was Ben Thompson at Stratechery’s Interview with Meta CTO Andrew Bosworth About Orion and Reality Labs, which included this phenomenal sentence:

Orion makes every other VR or AR device I have tried feel like a mistake — including the Apple Vision Pro.

There are a lot of things that make Space Glasses hard, but the really properly hard part is the lenses. You need something optically clear and distortion-free enough to do regular tasks while looking through, while also being able to display high-enough resolution content to be readable without eyestrain, and do all that will being spectacle lens–sized, stay in sync with each other, and do it all while mounted in something roughly glasses-sized, and ideally without shooting lasers at anyone’s eyeballs or having a weird prism sidecar.

The rest of it: chunky bodies, battery life, software, those aren’t “Easy”, but making those better is a known quantity; it doesn’t require super-science, it’s “just work.”

I’m personally inclined to believe that a Steve Jobs–esque “one more thing” surprise reveal is more valuable than a John Sculley–style fantasy movie about Knowledge Navigators, but if I’d solved the core problem with space glasses while my main competitor was mired in a swamp full of Playthings for the Alone, I’d probably flex too.

Software Forestry 0x02: What We Talk About When We Talk About Tech Debt

Tell me if this sounds familiar: you start a new job, or roll onto a new project, or even have a job interview, and someone says in a slightly hushed tone, words to the effect of “Now, I don’t want to scare you, but we have a lot of tech debt.” Or maybe, “this system is all Legacy Code.” Usually followed by something like “but don’t worry! We’ve got a modernization effort!”

Everyone seems to be absolutely drowning in “tech debt”; hardly a day goes by where you don’t read another article about some system with some terrible problem that was caused by being out of date, deferred maintenance, “in debt.” We constantly joke about the fragile house-of-cards nature of basically, everything. Everyone is hacking their way, pun absolutely intended, through overgrown forests.

There’s a lot to unpack from all that. Other engineering disciplines don’t beg to rebuild their bridges or chemical plants after a couple of years, but they also don’t need to; they build them to last. How does this happen? Why is it like this?

For starters, I think this is one of those places where our metaphors are leading us wrong.

I can’t now remember when I first heard the term Technical Debt. I think it was early twenty-teens, the place I was working in the mid-aughts had a lot of tech debt but I don’t ever remember anyone using that term, the place I was working in the early teens also had a lot, and we definitely called it that.

One of the things metaphors are for is to make it easier to talk to people with a different background—software developers and business folks, for example. We might use different jargon in our respective areas of expertise, but if we can find an area of shared understanding, we can use that to talk about the same thing. “Debt” seems like a kind of obvious middle-ground: basically everyone who participates in the modern economy has a basic, gut-level understanding of how debt works.

Except, do they have the same understanding?

Personally, I think “debt” is a terrible metaphor, bordering on catastrophic. Here’s why: it has very, very different moral dimensions depending on whose talking about it.

To the math and engineering types who popularized the term, “debt” is obviously bad, bordering on immoral. They’re the kind of people who played enough D&D as kids to understand how probability works, probably don’t gamble, probably pay off their credit cards in full every month. Obviously we don’t want to run up debt! We need to pay that back down! Can’t let it build up! Queue that scene in Ghostbusters where Egon is talking about the interest on Ray’s two mortgages.

Meanwhile, when the business-background folks making the decisions about where to put their investments hear that they can rack up “debt” to get features faster, but can pay it off in their own time with no measurable penalty or interest, they make the obvious-to-them choice to rack up a hell of a lot of it. They debt-financed the company with real money, why not the software with metaphorical currency? “We can do it, but that’ll add tech debt” means something completely different to the technical and business staff.

Even worse, “debt” as a metaphor implies that it ends. In real life, you can actually pay the debt off; pay off the house, end the car payment, pay back the municipal bonds, keep your credit cards up to date, whatever. But keeping your systems “debt free” is a process, a way of working, not really something you can save up and pay off.

I’m not sure any single metaphor has done more damage to our industry’s ability to understand itself than “tech debt.”

Of course, the definiton “tech debt” expanded and has come to encompass everything about a software system that makes it hard to work on or the developers don’t like. “Cruft” is the word Fowler uses. “Tech debt”, “legacy”, “lack of maintenance” all kind of swirl into a big mish-mash, meaning, roughly, “old code that’s hard to work on.” Which makes it even less useful as a metaphor, because it covers a lot of different kinds of challenges, each of which calls for different techniques to treat and prevent. In fairness, Fowler takes a swing at categorizing tech debts via the Technical Debt Quadrant, which isn’t terrible, but is a little too abstract to reflect the lived reality.

This is a place where our Forestry metaphor offers up an obvious alternate metaphor: Overgrowth. Which gets close to heart of what the problem feels like: that we built a perfectly fine system, and now, after no action on our part, its not fine. Weeds. There’s that sense that it gets worse when you’re not looking,

There’s something very vexing about this. As Joel said: As if source code rusted. But somehow, that system that was just fine not that long ago is old and hard to work on now. We talk about maintenance, but the kind of maintenance a computer system needs is very different from a giant engine that needs to get oiled or it’ll break down.

I think a big part of the reason why it seems so endemic nowadays is that there was a whole lot of appetite to rewrite “everything for the web” in either Java or .Net around the turn of the century, at the same time a lot of other software got rebuilt mostly from scratch to support, depending on your field, Linux, Mac OS X, or post-NT Windows. There hasn’t been a similar “replant the forest” mood since, so by the teens everyone had a decade-old system with no external impetus to rebuild it. For a lot of fields, this was the first point where we had to think in terms of long term maintenance instead of the OS vendor forcing a rebuild. (We all became mainframe programmers, metaphorically speaking.) And so, even though the Fowler article dates to ’03, and the term is older than that, “Tech Debt” became a twenty-teens concern. Construction stopped being the main concern, replaced with care and feeding.

Software Forests need a different kind of tending than the old rewrite-updates-rewrite again loop. As Foresters, we know the codebases we work on were here before us, and will continue on after us. The occasional greenfield side project, the occasional big new feature, but mostly out job is to keep the forest healthy and hand it along to the next Forester. It takes a different, longer term, continuous world view than counting down the number of car payments left.

Of course, there’s more than one way a forest can get out of hand. Next Time: Types of Overgrowth, catalogued

is it still called a subtweet if you use your blog to do it

There’s that line, that’s incorrectly attributed to Werner Herzog, that goes “Dear America: You are waking up, as Germany once did, to the awareness that 1/3 of your people would kill another 1/3 while 1/3 watches.” (It was actually the former @WernerTwertzog.)

But sure, false attribution aside, I grew up hearing stories about that. The reason my family lives on this side of the planet is because of reasons strongly adjacent to that. Disappointing, but not surprising, when that energy rears back up.

What does keep surprising me over the last few years, is that I never expected that last third to be so smug about it.

The next Dr Who Blu Ray release is… Blake’s 7?

It turns out the next Doctor Who blu-ray release is… the first season of Blakes 7? Wait, what? Holy Smokes!

I describe Blake's 7 as “the other, other, other, British Science fiction show”, implicitly after Doctor Who , The Hitchhiker's Guide to the Galaxy, and Red Dwarf. Unlike those other three, Blake didn’t get widespread PBS airings in the US (I’m not sure my local PBS channel ever showed it, and it ran everything.)

Which is a shame, because it deserves to be better known. The elevator pitch is essentially The Magnificent Seven/Seven Samurai in space”; a group of convicts, desperadoes, and revolutionaries lead a revolt against the totalitarian Earth Federation. In a move that could only be done in the mid-70s, the “evil Federation” is blatantly the Federation from Star Trek, rotted out and gone fascist, following a long line of British SF about fascism happening “here.”

It was made almost entirely by people who had previously worked on Doctor Who, and it shows; while there was never a formal crossover, the entire show feels like a 70s Who episode where the TARDIS just never lands and things keep getting worse. My other joke though, is that whereas Doctor Who’s budget was whatever change they could find in the BBC lobby couch cushions, Blake’s budget was whatever Doctor Who didn’t use. It’s almost hypnotically low budget, with some episodes so cheap that they seem more like avant garde theatre than they do a TV show whose reach is exceeding its grasp.

On the other hand, its got some of the best writing of all time, great characters, great acting. It revels in shades of gray and moral ambiguity decades before that came into vogue. And without spoiling anything, it has one of the all-time great last episodes of any show. It’s really fun. It’s a show I always want to recommend, but I’m not sure it ever got a real home video release in North America.

So a full, plugs out release is long overdue. The same team that does the outstanding Doctor Who blu-ray sets is doing this; same level of restoration, same kind of special features. Apparently, they’re doing “updated special effects”, except some of the original effects team came out of retirement and they’re shooting new model work? Incredible. The real shame is that so many of the people behind the show have since passed; both main writers, several of the actors, including the one who played the best character. Hopefully there’s some archive material to fill in the gaps.

Blake ran for 4 years, presumably the Doctor Who releases will stay and 2 a year with Blake getting that third slot.

Programming Note

Icecano will be off the air for the rest of this week.

and another thing: they’re not stranded. please don’t put in the newspaper that they’re stranded.

Well, three months in to an eight day mission, the Boeing Starliner made it back to earth, leaving its former crew hanging around at the orbital truckstop until February. What a bizarre episode in the history of human spaceflight, although my favorite part was when the spaceship started making strange noises .

It’s surprisingly hard to find a number for the actual amount of money NASA has handed Boeing so far for this rickety-ass “space” “ship”, but it seems to be somewhere in the $3–4 billion range?

And I know, in the annals of US tax dollars being misspent that number is very small, but while all this is going on the Chandra X-ray Observatory is basically holding a bake sale to stay in operation? Imagine what that money could have been spent on! That’s basically two full space telescopes, or one telescope with enough money left over to staff it forever. That’s two or three deep space probes. That’s a whole lot of fun science we could have done, instead of paying for an empty capsule cooling in the middle of the desert.

Software Forestry 0x01: Somewhere Between a Flower Pot and a Rainforest

“Software” covers a lot of ground. As there are a lot of different kinds and ecosystems of forests, there are a lot of kinds and ecosystems of software. And like forests, each of those kinds of software has their own goals, objectives, constraints, rules, needs.

One of the big challenges when reading about software “processes” or “best practices” or even just plain general advice is that people so rarely state up front what kind of software they’re talking about. And that leads to a lot of bad outcomes, where people take a technique or a process or an architecture that’s intrinsically linked to its originating context out of that context, recommend it, and then it gets applied to situations that are wildly inappropriate. Just like “leaves falling off” means something very different in an evergreen redwood forest than it does in one full of deciduous oak trees, different kinds of software projects need different care. As practitioners, it’s very easy for us to talk past each other.

(This generally gets cited in cases like “if you aren’t a massive social network with a dedicated performance team you probably don’t need React,” but also, pop quiz: what kind of software were all the signers of the Agile Manifesto writing at the time they wrote and signed it?¹)

So, before we delve into the practice of Software Forestry, let’s orient ourselves in the landscape. What kinds of software are there?

As usual for our industry, one of the best pieces written on this is a twenty-year old Joel On Software Article,² where he breaks software up into Five Worlds:

1. Shrinkwrap (which he further subdivides into Open Source, Consultingware, and Commercial web based)
2. Internal
3. Embedded
4. Games
5. Throwaway

And that’s still a pretty good list! I especially like the way he buckets not based on design or architecture but more on economic models and business contraints.

I’d argue that in the years since that was written, “Commercial web-based” has evolved to be more like what he calls “Internal” than “Shrinkwrap”; or more to the point, those feel less like discrete categories than they do like convenient locations on a continuous spectrum. Widening that out a little, all five of those categories feel like the intersections of several spectrums.

I think spectrums are a good way to view the landcape of modern software development. Not discrete buckets or binary yes/no questions, but continuous ranges where various projects land somewhere in between the extremes.

And so, in the spirit of an enthusiastic “yes, and”, I’d like to offer up what I think are the five most interesting or influential spectrums for talking about kinds of software, which we can express as questions sketching out a left-to-right spectrum:

1. Is it a Flower Pot or a Sprawling Forest?
2. Does it Run on the Customer’s Computers or the Company’s Computers?
3. Are the Users Paid to Use It or do they Pay to Use It?
4. How Often Do Your Customers Pay You?
5. How Much Does it Matter to the Users?

🌲

Is it a Flower Pot or a Sprawling Forest?

This isn’t about size or scale, necessarily, as mich as it is about overall “complexity”, the number of parts. On one end, you have small, single-purpose scripts running on one machine, on the other end, you have sprawling systems with multiple farms or clusters interacting with each other over custom messaging busses.

How many computers does it need? How many different applications work together? Different languages? How many versions do you have to maintain at once? What scale does it operate at?³ How many people can draw an accurate diagram from memory?

This has huge impacts on not only the technology, but things like team structure, coordination, and planning. Joel’s Shrinkwrap and Internal categories are on the right here, the other three are more towards the left.

🌳

Does it Run on the Customer’s Computers or the Company’s Computers?

To put that another way, how much of it works without an internet connection? Almost nothing is on one end or the other; no one ships dumb terminals or desktop software that can’t call home anymore.

Web apps are pretty far to the right, depending on how complex the in-browser client app is. Mobile apps are usually in the middle somewhere, with a strong dependency on server-side resources, but also will usually work in airplane mode. Single-player Games are pretty far to the left, only needing server components for things like updates and achievement tracking; multiplayer starts moving right. Embedded software is all the way to the left. Joel’s Shrinkwrap is left of center, Internal is all the way to the right.

This has huge implications for development processes; as an example, I started my career in what we then called “Desktop Software”. Deployment was an installer which got burned to a disk. Spinning up a new test system was unbelievably easy, pull a fresh copy of the installer and install it into a VM! Working in a micoservice mesh environment, there are days that feels like the software equivalent of greek fire, a secret long lost. In a world of sprawling services, spinning up a new environment is sometimes an insurmountable task.

A final way to look at this: how involved do your users have to be with an update?

🌲

Are the Users Paid to Use It or do they Pay to Use It?

What kind of alternate options do the people actually using the software have? Can they use something else? A lot of times you see this talked about as being “IT vs commercial,” but it’s broader than that. On the extreme ends here, the user can always choose to play a different mobile game, but if they want to renew their driver’s license, the DMV webpage is the only game in town. And the software their company had custom built to do their job is even less optional.

Another very closely related way of looking at this: Are your Customers and Users the same people? That is, are the people looking at the screen and clicking buttons the same people who cut the check to pay for it? The oft-repeated “if you’re not the customer you’re the product” is a point center-left of this spectrum.

The distance between the people paying and the people using has profound effects on the design and feedback loops for a software project. As an extreme example, one of the major—maybe the most significant—differences between Microsoft and Apple is that Microsoft is very good at selling things to CIOs, and Apple is very good at selling things to individuals, and neither is any good at selling things the other direction.

Bluntly, the things your users care about and that you get feedback on are very, very different depending on if they paid you or if they’re getting paid to use it.

Joel’s Internal category is all the way to the left here, the others are mostly over on the right side.

🌳

How Often Do Your Customers Pay You?

This feels like the aspect that’s exploded in complexity since that original Joel piece. The traditional answer to this was “once, and maybe a second time for big upgrades.” Now though, you’ve got subscriptions, live service models, “in-app purchases”, and a whole universe of models around charging a middle-man fee on other transactions. This gets even stranger for internal or mostly-internal tools, in my corporate life, I describe this spectrum as a line where the two ends are labeled “CAPEX” and “OPEX”.

Joel’s piece doesn’t really talk about business models, but the assumption seems to be a turn-of-the-century Microsoft “pay once and then for upgrades” model.

🌲

How Much Does it Matter to the Users?

Years and years ago, I worked on one of the computer systems backing the State of California’s welfare system. And on my first day, the boss opened with “however you feel about welfare, politically, if this system goes down, someone can’t feed their kids, and we’re not going to let that happen.” “Will this make a kid hungry” infused everything we did.

Some software matters. Embedded pacemakers. The phone system. Fly-by-wire flight control. Banks.

And some, frankly, doesn’t. If that mobile game glitches out, well, that’s annoying, but it was almost my appointment time anyway, you know?

Everyone likes to believe that what they’re working on is very important, but they also like to be able to say “look, this isn’t aerospace” as a way to skip more testing. And thats okay, there’s a lot of software that if it goes down for an hour or two, or glitches out on launch and needs a patch, that’s not a real problem. A minor inconvenience for a few people, forgotten about the next day.

As always, it’s a spectrum. There’s plenty of stuff in the middle: does a restaurant website matter? In the grand scheme of things, not a lot, but if the hours are wrong that’ll start having an impact on the bottom line. In my experience, there’s a strong perception bias towards the middle of this spectrum.

Joel touches on this with Embedded, but mostly seems to be fairly casual about how critical the other categories are.

🌳

There are plenty of other possible spectrums, but over the last twenty years those are the ones I’ve found myself thinking about the most. And I think the combination does a reasonable job sketching out the landscape of modern software.

A lot of things in software development are basically the same regardless of what kind of software you’re developing, but not everything. Like Joel says, it’s not like Id was hiring consultants to make UML diagrams for DOOM, and so it’s important to remember where you are in the landscape before taking advice or adopting someone’s “best practices.”

As follows from the name, Software Forestry is concerned with forests—the bigger systems, with a lot of parts, that matter, with paying customers. In general, the things more on the right side of those spectrums.

As Joel said 22 years ago, we can still learn something from each other regardless of where we all stand on those spectrums, but we need to remember where we’re standing.

🌲

Next Time: What We Talk About When We Talk About Tech Debt

---

1. I don’t know, and the point is you don’t either, because they didn’t say.
2. This almost certainly wont be the last Software Forestry post to act as extended midrash on a Joel On Software post.
3. Is it web scale?

That’s How You Do That

I’ve never been convinced that “debates” are a useful contribution to presidential campaigns; the idea that the candidates are going to do some kind of good faith high school debate club show is the same kind of pundit class galaxy brained take as “there are undecided voters." But then again, we’ve found ourselves with a system where the most powerful person in the world is selected by 6000 low-information people in rural Pennsylvania, so that results in some strange artifacts.

That said.

There’s your choice America. I can’t think of another occasion with that stark a contrast between candidates for anything. Both the best and the worst debate performance I’ve ever seen, on the same stage. Once again, Harris is proving that the way to deal with the convicted felon is to call him on his bullshit as clearly as possible and to his face. You love to see it.

With that said, I wish, I really wish, that some debate moderator would open with “so, we all know this isn’t about policy, this is about appearances and vibes, so I’m going to abandon the prepared questions and open with this: What’s your best joke?” Maybe move into the Voight-Kampff questions after that.

Internet Archive Loses Appeal

In an unsurprising but nevertheless depressing ruling, the Internet Archive’s has lost its appeal in the case about their digital library. (Ars, Techdirt.)

So let me get this straight; out of everything that happened in 2020, the only people facing any kinds of legal consequences are the Internet Archive, for checks notes letting people read some books?

Software Forestry 0x00: Time For More Metaphors

Software is a young field. Creating software as a mainstream profession is barely 70 years old, depending on when you start counting. Its legends are still, if just, living memory.

Young enough that it still doesn’t have much of its own language. Other than the purely technical jargon, it’s mostly borrowed words. What’s the verb for making software? Program? Develop? Write? Similarly, what’s the name for someone who makes software? Programmer? Developer? We’ve settled, more or less, on Engineer, but what we do has little in common with other branches of engineering. Even the word “computer” is borrowed; not that long ago a computer was something like an accountant, a person who computed.¹ None of this is a failing, but it is an indication of how young a field this is.

This extends to the metaphors we use to talk about the practice of creating that software. Metaphors are a cognitive shortcut, a way to borrow a different context to make the current one easier to talk about. But they can also be limiting, you can trap yourself in the boundaries of the context you borrowed.

Not that we’re short on metaphors, far from it! In keeping with the traditions of American Business, we use a lot of terms from both Sports (“Team”, “Sprint,” “Scrum”) and the Military (“Test Fire,” “Strategy vs. Tactics”). The seminal Code Complete proposed “Construction”. Knuth called it both an Art and a branch of Literature. We co-opted the term “Architecture” to talk about larger designs. In recent years, you see a lot of talk about “Craft.” “Maintenance-Oriented Programming.” For a while, I used movies. (The spec is the script! Specialized roles all coming together! But that was a very leaky abstraction.)

The wide spread of metaphors in use shows how slippery software can be, how flexible it is conceptually. We haven’t quite managed to grow a set of terms native to the field, so we keep shopping around looking for more.

I bring this up because what’s interesting about the choice of metaphors isn’t so much the direct metaphors themselves but the way they reflect the underlying philosophy of the people who chose them.

There’s two things I don’t like about a lot of those borrowed metaphors. First, most of them are Zero Sum. They assume someone is going to lose, and maybe even worse, they assume that someone is going to win. I’d be willing to entertain that that might be a useful way to think about a business as a whole in some contexts, but for a software team, that’s useless to the point of being harmful. There’s no group of people a normal software team interacts with that they can “beat”. Everyone succeeds and fails together, and they do it over the long term.

Second, most of them assume a clearly defined end state: win the game, win the battle, finish the building. Most modern software isn’t like that. It doesn’t get put in a box in Egghead anymore. Software is an ongoing effort, it’s maintained, updated, tended. Even software that’s not a service gets ongoing patches, subscriptions, DLC, the next version. There isn’t a point where it is complete, so much as ongoing refinement and care. It’s nurtured. Software is a continuous practice of maintenance and tending.

As such, I’m always looking for new metaphors; new ways of thinking about how we create, maintain, and care for software. This is something I’ve spent a lot of time stewing on over the last two decades and change. I’ve watched a lot of otherwise smart people fail to find a way to talk about what they were doing because they didn’t have the language. To quote every informercial: there has to be a better way.

What are we looking for? Situations where groups of people come together to accomplish a goal, something fundamentally creative, but with strict constraints, both physical and by convention. Where there’s competition, but not zero sum, where everyone can be successful. Most importantly, a conceptual space that assumes an ongoing effort, without a defined ending. A metaphor backed by a philosophy centered around long-term commitment and the way software projects sprawl and grow.

“Gardening” has some appeal here, but that’s a little too precious and small-scale, and doesn’t really capture the team aspect.² We want something larger, with people working together, assuming a time scale beyond a single person’s career, something focused on sustainable management.

So, I have a new software metaphor to propose: Software Forestry.

These days, software isn’t built so much as it’s grown, increment by increment. Software systems aren’t a garden, they’re a forest, filled with a whole ecosystem of different inhabitants, with different sizes, needs, uses. It’s tended by a team of practitioners who—like foresters—maintain its health and shape that growth. We’re not engineers as much as caretakers. New shoots are tended, branches pruned, fertilizer applied, older plants taken care of, the next season’s new trees planned for. But that software isn’t there for its own sake, and as foresters we’re most concerned with how that software can serve people. We’re focused on sustainability, we know now that the new software we write today is the legacy software of tomorrow. Also “Software Forestry” means the acronym is SWF, which I find hilarious. And personally, I really like trees.³ Like with trees, if we do out jobs right this stuff will still be there long after we’ve moved on.

It’s easy to get too precious about this, and let the metaphor run away with you; that’s why there were all those Black Belts and Ninjas running around a few years ago. I’m not going to start an organization to certify Software Rangers.⁴ But I think a mindset around care and tending, around seasons, around long-term stewardship, around thinking of software systems as ecosystems, is a much healthier relationship to the software industry we actually have than telling your team with all seriousness that we have to get better at blocking and tackling. We’re never going to win a game, because there’s no game to win. But we might grow a healthy forest of software, and encourage healthier foresters.

Software Forestry is a new weekly feature on Icecano. Join us on Fridays as we look at approaches to growing better software. Next Time: What kind of software forests are we growing?

---

1. My grandmother was a “civillian computer” during the war, she computed tables describing when and how to release bombs from planes to hit a target; the bombs in those tables were larger than normal, needing new tables computed late in the war. She thought nothing of this at the time, but years later realized she had been working out tables for atomic bombs. Her work went unused, she became a minister.

2. Gardening seems to pop up every couple of years; searching the web turns up quite a few abandoned swings at Software Gardening as a concept.
3. I did briefly consider “Software Arborists”, but that’s a little too narrow.
4. Although I assume the Dúnedain would make excellent programmers.

Ableist, huh?

Well! Hell of a week to decide I’m done writing about AI for a while!

For everyone playing along at home, NaNoWriMo, the nonprofit that grew up around the National Novel Writing Month challenge, has published a new policy on the use of AI, which includes this absolute jaw-dropper:

We also want to be clear in our belief that the categorical condemnation of Artificial Intelligence has classist and ableist undertones, and that questions around the use of Al tie to questions around privilege.

Really? Lack of access to AI is the only reason “the poors” haven’t been able to write books? This is the thing that’s going to improve access for the disabled? It’s so blatantly “we got a payoff, and we’re using lefty language to deflect criticism,” so disingenuine, and in such bad faith, that the only appropriate reaction is “hahahha Fuck You.”

That said, my absolute favorite response was El Sandifer on Bluesky:

"Fucking dare anyone to tell Alan Moore, to his face, that working class writers need AI in order to create."; immediately followed by "“Who the fuck said that I’ll fucking break his skull open” said William Blake in a 2024 seance."

It’s always a mistake to engage with Bad Faith garbage like this, but I did enjoy these attempts:

You Don't Need AI To Write A Novel - Aftermath

NaNoWriMo Shits The Bed On Artificial Intelligence – Chuck Wendig: Terribleminds

There’s something extra hilarious about the grifters getting to NaNoWriMo—the whole point of writing 50,000 words in a month is not that the world needs more unreadable 50k manuscripts, but that it’s an excuse to practice, you gotta write 50k bad words before you can get to 50k good ones. Using AI here is literally bringing a robot to the gym to lift weights for you.

If you’re the kind of ghoul that wants to use a robot to write a book for you, that’s one (terrible) thing, but using it to “win” a for-fun contest that exists just to provide a community of support for people trying to practice? That’s beyond despicable.

The NaNoWriMo organization has been a mess for a long time, it’s a classic volunteer-run non-profit where the founders have moved on and the replacements have been… poor. It’s been a scandal engine for a decade now, and they’ve fired everyone and brought in new people at least once? And the fix is clearly in; NoNoWiMo got a new Executive Director this year, and the one thing the “AI” “Industry” has at the moment is gobs of money.

I wonder how small the bribe was. Someone got handed a check, excuse me, a “sponsorship”, and I wonder how embarrassingly, enragingly small the number was.

I mean, any amount would be deeply disgusting, but if it was, “all you have to do is sell out the basic principles non-profit you’re now in charge of and you can live in luxury for the rest of your life” that’s still terrible but at least I would understand. But you know, you know, however much money changed hands was pathetically small.

These are the kind of people who should be hounded out of any functional civilization.

---

And then I wake up to the news that Oprah is going to host a prime time special on The AI? Ahhhh, there we go, that’s starting to smell like a Matt Damon Superbowl Ad. From the guest list—Bill Gates?—it’s pretty clearly some high-profile reputation laundering, although I’m sure Oprah got a bigger paycheck than those suckers at NaNoWriMo. I see the discourse has already decayed through a cycle of “should we pre-judge this” (spoiler: yes) and then landed on whether or not there are still “cool” uses for AI. This is such a dishonest deflection that it almost takes my breath away. Whether or not it’s “cool” is literally the least relevant point. Asbestos was pretty cool too, you know?

And Another Thing… AI Postscript

I thought I was done talking about The AI for a while after last week’s “Why is this Happening” trilogy (Part I, Part II, Part III,) but The AI wasn’t done with me just yet.

First, In one of those great coincidences, Ted Chiang has a new piece on AI in the New Yorker, Why A.I. Isn’t Going to Make Art (and yeah, that’s behind a paywall, but cough).

It’s nice to know Ted C. and I were having the same week last week! It’s the sort of piece where once you start quoting it’s hard to stop, so I’ll quote the bit everyone else has been:

The task that generative A.I. has been most successful at is lowering our expectations, both of the things we read and of ourselves when we write anything for others to read. It is a fundamentally dehumanizing technology because it treats us as less than what we are: creators and apprehenders of meaning. It reduces the amount of intention in the world.

Intention is something he locks onto here; creative work is about making lots of decisions as you do the work which can’t be replaced by a statistical average of past decisions by other people.

Second, continuing the weekend of coincidences, the kids and I went to an Anime convention this past weekend. We went to a panel on storyboarding in animation, which was fascinating, because storyboarding doesn’t quite mean the same thing in animation that it does in live-action movies.

At one point, the speaker was talking about a character in a show he had worked on named “Ai”, and specified he meant the name, not the two letters as an abbreviation, and almost reflexively spitted out “I hate A. I.!” between literally gritted teeth.

Reader, the room—which was packed—roared in approval. It was the kind of noise you’d expect to lead to a pitchfork-wielding mob heading towards the castle above town.

Outside of the more galaxy-brained corners of the wreckage of what used to be called twitter or pockets of techbros, real people in the real world hate this stuff. I can’t think of another technology from my lifetime that has ever gotten a room full of people to do that. Nothing that isn’t armed can be successful against that sort of disgust; I think we’re going to be okay.