See what's become of me ... while I looked around ...

I had a couple of ideas for a post this week, but I’m preparing to head off to Cachuma Lake for a vacation with The Mother and my youngest.  So I’ve been spending a good deal of my weekend getting ready for that.  I just haven’t had time to put together a proper post, and, next week, I’ll just be getting back from this vacation, so you’re not likely to see a full post then either.  Sorry about that.  But sometimes you jsut gotta put family first.

You know?

Don´t know why ... there´s no sun up in the sky ...

Today, we are getting a visit from Tropical Storm Hilary, which is just lovely.  I figured I’d traded all my hurricanes for earthquakes when I moved from the East Coast here to sunny Southern California.  But, if you can believe this shit, we actually had an earthquake during the tropical storm.  It was a 5.1, which is a decent-sized quake, as SoCal earthquakes go, but it was also only about 28 miles away from our house.  The house swayed like a North Carolina beach house in a tropical storm—for a few seconds I thought it actually was the tropical storm, but of course houses built on a foundation don’t really do that.

So, the earthquake was a minor bit of excitement in the midst of the ongoing torrential downpour, which is already starting to come through our garage roof.  Gotta look into getting that fixed at some point.  When you live in the desert, leaky roofs are not usually a priority.  But this year has been a bit of an exception in the rainfall department.

So the rain beats a loud tattoo on the patio outside the open window behind my head, and I continue to wait for the power to go out, though hopefully the solar battery will kick in.  And the encroaching night blankets us all.

Next week, something longer.

Perception, Investigation: a Perpetual Imbroglio

Today I want to talk about the difference between two things that are consistently mixed up in D&D 5e: Perception and Investigation.  This is ostensibly a gaming topic, of interest to people who play (or just watch) TTRPGs such as D&D, but I’m going to make an argument that it’s actually rather fascinating from a linguistic perspective as well.  This is one of those rare topics where I can explore language and give gaming advice all at the same time.

So, first of all, what actually is the problem here?  Simply put, D&D characters have skills—certain things that they’re good at, or not so good at—and, when the character attempts to do something (well, something that isn’t swinging a sword or casting a spell), it’s the GM’s job to decide which skill applies.  Sometimes there can be a bit of back and forth on this: for instance, two of the skills in 5e are Athletics and Acrobatics.  Athletics is based on Strength, and it’s what you use when you want to climb, jump, swim, or grapple.  Acrobatics, on the other hand, is based on Dexterity, and it’s what you use when you want to dodge, tumble, or flip.  You could imagine a scenario where a player says what they want to do and the GM says, “great, give me an Athletics check,” to which the player replies: “ummm, can I use Acrobatics instead?” Obviously, they ask this because they have a higher Dexterity than they do Strength, or they’re proficient in the one but not the other.  You could even imagine a scenario where either skill could be used (say, the user wants to negate damage from falling, and they could either employ their jumping skills or their tumbling skills), and the GM might change their minds.  Sometimes the GM just does this not to be a hardass—after all, we’re playing a game here, not trying to outwit each other or trick each other into rolling poorly—but sometimes the GM can see it either way, or the GM is just persuaded of the player’s point of view.  And that’s fine.

What’s less fine is if the GM doesn’t really know which one is the right answer.  As a GM, one needn’t be perfect, of course, but one should strive to understand the things that come up often.  And, if you watch any streaming D&D games (which is easy to do these days), you may see a scenario like I describe above between Athletics and Acrobatics ... but you will almost certainly see one involving Perception and Investigation.

And here’s the thing: once you have a good grasp on the difference between the two, it’s way less common to find a situation where they really are interchangeable.  I can’t count the number of times where I’ve watched GMs—really really good GMs, even—say, “ah, sure, you can use Perception here,” or even (and I shudder to even type the words) “give me a Perception check or Investigation check: your choice.” Now, I’m more of a yell-at-the-screen sort of critic than a post-snarky-corrections-in-the-comments-section one, so, if I want to publicize my opinion on this issue, this blog is where I do it.

Now, I’m hardly the first person to realize this is a problem.  A cursory Internet search will reveal article after article (after article) telling you how to distinguish between the two.  The problem is, most of them give conflicting advice, so they can’t all possibly be right.  This leads to many (many) instances of people on the Internet asking for help ... for which they receive—you guessed it—conflicting advice.  And the problem is, even if you try to find a common thread from all those, you’re probably going to find the wrong one.

See, the general concensus of the Internet is, since Perception is based on Wisdom while Investigation is based on Intelligence, Investigation should only be used to understand the things that you see (using Perception).  Investigation, this line of reasoning goes, is all about drawing conclusions and deductions based on obersvations.  But there’s a fundamental problem with that: it contradicts the actual rules.  Here’s what the rules say about Investigation:

When you look around for clues and make deductions based on those clues, you make an Intelligence (Investigation) check.

So the deducing is part of the Investigation, sure, but so is the looking.  Fine, then: what do the rules say about Perception?

Your Wisdom (Perception) check lets you spot, hear, or otherwise detect the presence of something.

Hmm ... that also seems to involving looking.  No wonder people are confused.

Now, I should first note that neither skill has to involve looking.  You can perceive things with your ears or your nose, and you can investigate things with your hands or your brain.  But those aren’t the cases that confuse us, as it turns out.  If the player says “I listen to see if I can hear anyone following us” and the GM asks for a Perception check, no one is going to try to talk them into Investgation (or at least no one I’ve ever heard of); likewise, if the player says “I want to try to decipher this code” and the GM asks for Investigation, no serious player is going to try to convince them that it should be Perception instead.  It’s only when the visual sense comes into it—and we human beings are primarily visual creatures, so it tends to come into it quite a lot—that people tend to get confused.

As I mentioned, this has been debated a lot.  I wouldn’t want to weigh in if I didn’t feel like I had something new to contribute.  So here’s where I endorse my potentially revolutionary, potentially controversial take on this dilemma: it’s all about the verbs.  And the verb at the heart of this bewildering issue is “look.”

And what’s really fascinating to me is that it reminds me of my high school Spanish.  The way I was taught (and I’m sure it was a gross oversimplification designed to be able to be grasped by teenage brains) is that if you want to say you’re looking at something, you use mirar, but if you want to say you’re looking for something, then it’s buscar.  So when a native Spanish speaker tells you “miré la playa,” you understand that they went to the beach and just enjoyed the view.  But if on the other hand they say “busqué la playa,” then you know that they were trying to find the beach in the first place.  “I looked at the beach” (or “I watched the beach”) vs “I looked for the beach” (or “I searched for the beach”).  This is only hard for us English speakers because we’re so used to having one word for both concepts.  But, when you think about it, it’s actually easier and nicer to have the two different words: avoids any ambiguity.  “What’s the deal with the beach?” “Oh, I’m still looking.” Does that mean you refused to leave the beach because the view is so awesome, or that you can’t figure out how to use the map app on your phone so you never even got there?  No way to tell in English.  But, in Spanish, it wouldn’t even be a question: “todavía miro” and “todavía busco” are two entirely different replies.

I have no way to prove this, but I feel very confident in saying that Spanish-speaking D&D players and GMs have no confusion about Perception and Investigation at all: Perception is mirar, and Investigation is buscar.  Case closed.

But us poor non-speakers of Spanish need some guidance, yes?  Very well then, here’s my advice (to both GMs and players): expunge the word “look” from your vocabulary.  That’s it.  That’s all it takes.  Don’t tell your GM “I want to look and see if I see a clue”; say instead either “I want to try to notice a clue” or “I want to try to search for a clue.” If you can replace “look” with “observe” or “notice,” that’s Perception.  If you can replace it with “search” or “examine,” that’s Investigation.  That’s really all there is to it.

Now, I do want to address another aspect that seems to flummox people: the amount of time taken by the two actions.  One of those links above contains this gem of wisdom:

Often, DMs think that the difference between perception and investigation is simply how long the player wants to take to search. But this is NOT the case.

(Emphasis in the original.)  To which I respond: well, yes ... and no.  What they say is technically true.  The amount of time taken should never be the determining factor in which skill applies.  However, as a practical matter, it really is the case that “noticing” or “observing” typically takes a very small amount of time, while “searching” or “examining” takes much longer.  We could come up with counter-examples, of course: a Perception check to see if you notice anything during your 3-hour turn on watch duty, or an Investigation check to see if you can have a flash of inspiration while examining a puzzle with the walls closing in on you.  But, in general, Perception happens in an instant and Investigation takes time.  Which brings up another thorny issue: doing these things in combat.  See, in D&D a round of combat takes (in theory) 6 seconds.  During those 6 seconds, you can move (up to 30 feet, typically), and take an action, and maybe even take a bonus action (such as hiding if you’re a rogue, or getting in one more punch to the face if you’re a monk), and take a free “object interaction” (such as drawing a weapon or opening an unlocked door).  The main action for the turn thus has to fit in a very small number of seconds, certainly no more than 3.  You are not going to be searching a room in 3 seconds.  Contrariwise, it simply doesn’t take 3 whole seconds to look around and notice something.  I would never charge my player a whole action to take a Perception check in combat, but I would also never let my player get away with an Investigation check in combat, unless perhaps they devoted all their attention to it, and even then it would probably be an astronomically high DC.  Yet making players use their action for Perception is very common in streaming D&D such as Critical Role, and allowing them to do so for Investigation is not unheard of either.  I have to say, these calls don’t make a lot of sense to me.

Of course, several of the links I listed above will tell you that I’m completely wrong about searching for clues being an Investigation check.  Here’s some examples:

... Investigation focuses on interpreting the clues found with Perception checks.

However, the way I think of it is that Perception is to spot something like a clue, and Investigation is to work out what that clue means.

... to draw conclusions from the clues you’ve used perception to gather.

There’s only one problem with this theory: it’s not what the rules say. “When you look around for clues ... you make an Intelligence (Investigation) check” seems pretty clear to me.  I respect the distinction that these authors are trying to draw: a skill based on your Wisdom means you’re using intuition and awareness, while one based on Intelligence means you’re using logic and reasoning.  Unfortunately, trying to get too detailed on things like this is always going to break down.  To return to my first example of conflicting skills, your natural dexterity absolutely impacts your ability to climb, but it’s still an Athletics check; the strength of your muscles is definitely a factor when you’re swinging on a rope like a trapeeze artist, but it’s still an Acrobatics check.  D&D is not a perfect simulation—no TTRPG can be—and sometimes you just gotta go, well, this skill is for this action and this is what ability the book says goes with it ... don’t overthink it.

So, if you play D&D (and especially if you GM it), hopefully this will help you figure out which skill to apply when it seems confusing.  And, even if you don’t, hopefully you’ve had some inspirations as to how the subtleties of language impact every part of our lives: even the most unlikely ones.

The story of this week

This week, I actually made a passable start on catching up on a few things.  Plus, it continues to be hot as hell here in Southern Cali, and The Mother and my youngest attend a “bunny faire.” Next week, a proper post.

Eldritch Ætherium IV

"Tales Around the Desert Crossroads between Aribeth and Anauroch, over the High Seas, beyond the Druid Grove"

[This is one post in a series about my music mixes.  The series list has links to all posts in the series and also definitions of many of the terms I use.  You may wish to read the introduction for more background.  You may also want to check out the first volume in this multi-volume mix for more info on its theme.

Like all my series, it is not necessarily contiguous—that is, I don’t guarantee that the next post in the series will be next week.  Just that I will eventually finish it, someday.  Unless I get hit by a bus.]

Well, it’s another volume of music to inspire tabletop roleplaying, and yet again we’ve got another long, silly title cobbled together from the track names—I may have actually reached the limit at this point, and whenever next volume comes along I’ll probably have to reset to a shorter title and start building up again from there.  Many other things are the same too: Midnight Syndicate is back, with two more tracks off the excellent Dungeons & Dragons album, as are Nox Arcana, Colm McGuinness, and Ian Peter Fisher.  Jeremy Soule’s soundtrack for Neverwinter Nights, which exploded into this mix last volume with 3 tracks, now appears with a whopping four (but they’re all very short); Adrian von Ziegler (from volume II) finally returns; and we have two more tracks from both the 13th Age soundtrack (from two different composers: Chris J Nairn and Thery Ehrlich) and Michael Hoenig’s Baldur’s Gate II soundtrack.  Not to mention another track from the World of Warcraft soundtrack, and two more from the Witcher 3, including our amazing opener.

But of course we must have differences too.  For the first time, I don’t feature a track from the Shards of Eberron album that arguably inspired this whole mix.  There’s no Dead Can Dance this time out either, nor any zero-project.  Missing too are Epic Soul Factory and Faith and the Muse, and, perhaps most disappointing of all, no Loreena McKennitt.  Still, changes also mean new artists, and, to make up for McKennitt’s absence, we have a great piece from violinist Lindsey Stirling.  Stirling is one of those musical success stories that are truly inspirational:  She asked her parents for violin lessons and dance lessons, but they told her they could only afford one.  So she stuck with the violin lessons and taught herself to dance.  Then she started developing an act where she danced while playing violin, and everyone told her that no one wanted to see that.  So she took her impressive skills to YouTube and proved everyone wrong by amassing 13 million subscribers and over 3 billion views.  Stirling’s music is remarkable all on its own, but for the full effect you really have to visit her YouTube channel; you could start with the video for the track I use here, “The Arena.”  This track has a bit of the McKennitt flair, but it’s also transcendently Stirling.  She has a fondness for fantasy-themed music (such as her Skyrim tribute with Peter Hollens), and I thought “The Arena” fit right in here.

I’ve also found a couple of new soundtracks to mine.  Greg Edmonson’s score to Uncharted: Drake’s Fortune, for instance, works well here; franchises such as Indiana Jones, Tomb Raider, and Uncharted have a lot of traipsing around in jungles and ancient temples, which sort of makes them first cousins to D&D-style adventures.  Then there’s the Assassin’s Creed franchise, which is even closer to your average D&D campaign.  Here I’ve chosen one track from Jesper Kyd’s score for the first installment, and one from Brian Tyler’s for the fourth.  Staying on the videogame kick, we’ve got one track from Yuka Kitamura off the Dark Souls III soundtrack and one from Christopher Larkin’s excellent soundtrack for Hollow Knight, and even more Jeremy Soule, this time from his score for Oblivion, the Elder Scrolls game that immediately preceded Skyrim.

As our journey begins this time out, we’re sitting around a campfire with “Geralt of Rivia” telling “Tales Around the Fire”: after a hushed introduction, they start out quite dramatically, but soon lapse into a comfortable rhythm.  The next morning we begin traveling, exploring fantastical vistas and “Kismet,” which lead us to a “Night on the Desert,” where spooky things lurk in the darkness.  This brings us to a “Crossroads” of conscience, but we forge on into the dark, where mystical things await (“Soft Mystical Fantasy Theme”).  We stalk the magic by doing a bit of “Grave Robbing,” and the danger builds to an “Earth Shaker.”  Then we’re immediately plunged into “Battle Aribeth.”

In its aftermath, “The Eyes of the Stone Thief” are upon us, leading to some creepy feelings of being watched.  But we forge on through the jungle, danger lurking at every turn (“Plane-Wrecked”), and then there’s a sudden “Skirmish,” from which we emerge victorious.  Then we must embark on a “Journey Through Anauroch,” which is apparently a romantic, foreign land, but, “In the End,” it is the dramatic bass tones of “Fjölnir” that lead us inevitably to “The Arena.”

After a whirlwind adventure on that field, it’s off to “The High Seas” where we end up “Commanding the Fury” in fierce ship-to-ship combat.  We arrive at our destination just in time for a “City Battle”; fleeing from that encounter, we pass through the sinister and eerie “Stranglethorn Vale” where we have a “Premonition” of danger, so it’s off to “Waterdeep, City of Splendors”—which we find has some similarities to the “City of Jerusalem”—to search for a “Secret Sanctuary.”  There we encounter the “Sœurs martiales” (martial sisters) in all their stately grandeur.  That inevitably takes us to the “Final Confrontation” and bestows upon us our “Bloody Blades.”  We acquire healing from “The Druid Grove” and reflect on fallen comrades (“Trost” is German for “consolation”).  Our journey is done, but the dramatic airs of the “Reign of the Septims” remind us that further adventures await on the morrow.

Eldritch Ætherium IV
[ Tales Around the Desert Crossroads between Aribeth and Anauroch, over the High Seas, beyond the Druid Grove ]

“Geralt of Rivia” by Marcin Przybyłowicz, off The Witcher 3: Wild Hunt Soundtrack [Videogame Soundtrack]
“Tales Around the Fire” by Chris J Nairn, off The 13th Age Suite [RPG Soundtrack]
“Kismet” by bond, off Born
“Night on the Desert” by Jeremy Soule, off Neverwinter Nights [Videogame Soundtrack]
“Crossroads” by Christopher Larkin, off Hollow Knight [Videogame Soundtrack]
“Soft Mystical Fantasy Theme” by Ian Peter Fisher, off Soundtrack Music
“Grave Robbing” by Greg Edmonson, off Uncharted: Drake's Fortune [Videogame Soundtrack]
“Earth Shaker (Drums)” by audiomachine [Single]
“Battle Aribeth” by Jeremy Soule, off Neverwinter Nights [Videogame Soundtrack]
“The Eyes of the Stone Thief” by Thery Ehrlich, off The 13th Age Suite [RPG Soundtrack]
“Plane-Wrecked” by Greg Edmonson, off Uncharted: Drake's Fortune [Videogame Soundtrack]
“Skirmish” by Midnight Syndicate, off Dungeons & Dragons [RPG Soundtrack]
“Journey Through Anauroch” by Jeremy Soule, off Neverwinter Nights [Videogame Soundtrack]
“In the End” by Eklipse, off A Night in Strings
“Fjölnir” by Adrian von Ziegler, off Fable
“The Arena” by Lindsey Stirling, off Brave Enough
“The High Seas” by Brian Tyler, off Assassin's Creed IV: Black Flag [Videogame Soundtrack]
“Commanding the Fury” by Mikolai Stroinski, off The Witcher 3: Wild Hunt Soundtrack [Videogame Soundtrack]
“City Battle II” by Michael Hoenig, off Baldur's Gate II: Shadows of Amn [Videogame Soundtrack]
“Stranglethorn Vale” by Jason Hayes, off World of Warcraft Soundtrack [Videogame Soundtrack]
“Premonition” by Yuka Kitamura, off Dark Souls III Soundtrack [Videogame Soundtrack]
“Waterdeep, City of Splendors” by Jeremy Soule, off Neverwinter Nights [Videogame Soundtrack]
“City of Jerusalem” by Jesper Kyd, off Assassin's Creed [Videogame Soundtrack]
“Secret Sanctuary” by Nox Arcana, off Winter's Majesty
“Sœurs martiales” by Xcyril, off Coeur Martial [Soundtrack]
“Final Confrontation” by Midnight Syndicate, off Dungeons & Dragons [RPG Soundtrack]
“Bloody Blades” by Jeremy Soule, off The Elder Scrolls IV: Oblivion [Videogame Soundtrack]
“The Druid Grove” by Michael Hoenig, off Baldur's Gate II: Shadows of Amn [Videogame Soundtrack]
“Trost” by Colm McGuinness [Single]
“Reign of the Septims” by Jeremy Soule, off The Elder Scrolls IV: Oblivion [Videogame Soundtrack]

Total:  30 tracks,  78:23

Whew! that’s a lot of tracks.  In fact, this is not only our longest volume title so far, but also our longest in terms of number of tracks (though not in terms of total time—9 of the songs are under 2 minutes, and another 12 are between two and three minutes).  There’s not a whole lot unexpected going on here, but let’s look at what there is.

You may recall French composer Xcyril from his two appearances on Phantasma Chorale I and his single track on Paradoxically Sized World VI.  Those other tracks were from what I believed to be “soundtrack portfolios”—that is a collection of tunes that are likely used to demonstrate the composer’s skills and hopefully net them a job.  Well, the track here appears to be from an actual movie—if a very short and experimental one (you can watch it yourself and form your own opinion)—called Coeur Martial.  So I guess it worked.  There’s also a track from Audiomachine, an LA-based production company that does music for film and television.  I can’t remember how I stumbled across “Earth Shaker (Drums)” (which is, by the way, different from “Earth Shaker”), but I think I saw that someone on the Internet had cobbled together a playlist for one of the D&D adventures (Tomb of Annihilation, perhaps) and this one I thought was just too perfect.

And that just leaves us with the two string quartets, both of which are attempting to update that very classical sound with a lot of modern production values.  First we have Australia’s bond, who play chamber music infused with a lot of glam, and perform it much like a girl group.  Their first album Born has a lot of great tracks on it, but “Kismet” was the one that I thought really gave that feel of traveling through a fantasy landscape.  Last but not least, Germany’s Eklipse do chamber music covers of pop songs and dress like über-goths.  Their first album, A Night in Strings, has some great covers, including this one, “In the End.”  It’s a bit of a challenge to take a Linkin Park song and recontextualize it as a fantasy theme, but Eklipse did most of the work, and I think sandwiching it between Jeremy Soule and Adrian von Ziegler adds a bit as well.

Next time, we’ll take a second look at some indie ladies.

⇐ Eldritch Ætherium III

Eldritch Ætherium V ⇒

CollabGPT

This week I’ve been concentrating on setting up my file synchronization and versioning system.  For this, I’ve mainly been consulting with ChatGPT.  I originally wanted to hire an actual person to help me design and set this up, but I couldn’t find anyone who was both willing to work on my home system—what with me not being a business—and who seemed trustworthy (no shortage of shady characters, of course, but working on your network necessarily involves giving out your password, which is probably a Bad Thing to do in the case of randos on the Internet).  So I eventually decided to just ask ChatGPT and do whatever it said.

Well, perhaps not whatever it said, but, if you’re willing to put in a bit of effort to chastise it when it says something stupid and challenge it when it says something unlikely, you can actually get quite a lot out of it.  And it’s useful both in the design phase as well as the implementation phase.  Just about the only downside is that you have to start every chat fresh from ground zero (though there’s a new experimental feature which helps with that, a little).  And you can’t get around that by just staying in the same chat forever, because ChatGPT has a limited number of “tokens” (roughly equivalent to words) that it can remember before it starts forgetting the earliest parts of the conversation.

Still, you can get quite a lot accomplished even so.  Thanks to ChatGPT, I now have a system whereby I use Syncthing to handle synchronization across computers, and also provide versioning so that I can go back to the previous version of any file.  Now I’m working on getting that backed up to the cloud.

One of the fun things about ChatGPT’s limited memory is that sometimes you have to explain to it what it already figured out.  Today I started a new chat on this topic, as the old one was getting pretty full.  I told it:

I’ve designed a file synchronization and versioning system that works like this:
* There are seven shares, each of which is a filesystem with gigabytes of files.
* Haven and Avalir each have copies of six of the seven shares (there is one share that is not needed on each of those machines).
* Files are bidirectionally synchronized between Haven and Avalir using Syncthing.  No file versioning is used for these two servers.
* Zadash has a copy of all seven shares, with full file versioning (by which I mean keeping a copy of all versions forever).
* Editing of the files is done on Haven or Avalir only.  Since Syncthing only stores versions for remote edits, not local edits, if I edited files on Zadash, it would keep the previous version.  I do mount the shares from Haven to Zadash JIC I need to edit on Zadash, but the Syncthing copy is for archival purposes only.

To which ChatGPT responded:

You’ve outlined quite an advanced file synchronization system, ...

And I’m like, bitch, this was all your idea!

Anyways, that’s how my week went.  Next week, a longer topic, hopefully.

Of Waterfalls, Pigs, and Red Red Tape

Once upon a time we used to develop software via something known as the “waterfall model.”  When trying to envision this, don’t think about something like Angel Falls, where the water just falls off a cliff.  Picture instead something along the lines of Detian Falls in Vietnam: a series of steps as the water drops, level by level, to its final destination.  See, back in those olden times (which, honestly, were mostly before I got into the industry, though there was some residual inertia even in the mid-80s, when I came along), back then, as I say, the specifications (or “specs”) were developed by one team, who then passed them along to the design team, who designed the whole system in a very abstract way, and then passed it along to the programming team, who did all the hard coding work, and then passed it along to the QA team, who verified that the functionality matched the original specs, and then they passed it on the customer and then it’s done.  The primary reason for the analogy to a waterfall for this development model is that the water only flows one way: for the real-world waterfall, that’s due to gravity, and for the waterfall model, it’s because going backwards—“upstream,” if you will—is expensive.  You really want to get each phase just perfect, because if you find a mistake, you essentially have to start over ... and that costs the company money.  Sometimes, with this model, starting over was so expensive that they just didn’t.  The greatest stories of software development debacle were due to the sunk cost fallacy: too expensive to try get back up to the top of the waterfall, so we just gotta make due with whatever horror show we’ve ended up with.

So throughout the 80s and 90s software developers started saying there had to be a better way.  In 1986 the “spiral model” was proposed: it was built into the system that, instead of planning out the whole system at the beginning, you’d spec out just an initial prototype, then design that, code it, test, then go back to the spec stage and tack on more features.  Starting over was no longer a bug, but a feature.  Instead of losing a bunch of money because we had to start everything from scratch, we were only starting the next thing from scratch ... and, if we needed to tweak some stuff from the first iteration, well, we already had the mechanisms in place for specifying, desiging, coding, and testing.  Those phases were in our past, true: but they were also in our future.

Of course, the spiral model is a very abstract concept.  How do you actually implement such a thing?  That is, what are the actual processes that you put into place to make sure the company and its employees follow the model and achieve the goals of iterative design?  For that, we needed to move beyond models and into methodologies.  Enter Agile.

Agile software development practices, usually just referred to as “Agile,” were a way to concretize the spiral model abstraction.  Sometimes they would propose tweaks to the model, sure, but the main thing was, no going back to waterfall.  And, to distance themselves from those crusty old waterfall methodologies—many of which were by this point formalized as standards, such as the DOD’s 2167A—they all had cool new names: RAD (“Rapid Application Development”) and Scrum and Crystal Clear and Extreme Programming (if you didn’t just hear a Bill and Ted’s-style guitar lick, you’re doing it wrong).  This last one, usually abbreviated to “XP” (no relation to the Windows version) was not the first agile methodology to come along ... but it was the first one I was ever exposed to, and they say you never forget your first.

Kent Beck, author of “Extreme Programming Explained,” presented to me a perspective that literally changed my (software development) life.  He pointed out that, in order for the waterfall model to work, you have to be able to predict the future.  The whole thing is predicated on predicting what problems will happen, anticipating them, and building them into the plan.  If you fail to predict something, then everything falls apart.  Except ... humans really suck at predicting the future.  When we say “predict,” what we really mean is “guess.”  And we usually guess wrong.  As Kent so succinctly put it:

The problem isn’t change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes.

Stop trying to keep change from happening: it’s a fool’s errand.  Rather, create a better methodology which says “yeah, things change: so what? we got that covered.”

Agile is all about being flexible.  Hell, the reason it’s called “agile” is because the old waterfall methodologies were ponderous and slow to course-correct.  It’s common for business people to talk about agility in terms of responding to changes in the market: the creators of the Agile Manifesto (one of whom was Beck himself) wanted to capitalize on that perception.  Our development practices can make your company more agile, and that makes you quicker to respond, and that helps you beat your competitors.

And yet ... it’s kind of strange that we need all these procedures and guideliness and principles and a whole friggin’ manifesto to perform something for which the entire purpose is to be flexible.  The thing I never liked about XP, despite all its merits (and the aforementioned life-changing-ness), was that it had all these notes about how, if you’re not following every single rule, then you’re not “doing” XP.  You’re just playing at it.  I always found that inherent dichotomy cognitively dissonant: so I have to do things exactly according to these rules so that I can break the rules? I have to rigidly fit into the straitjacket so that I can have the flexibility to move freely? I have to precisely walk the straight line so that I have the freedom to jump in any direction?  Surely you see the contradiction.

And XP is certainly not alone in this strange philosophy.  I’m not sure we can claim any of the Agile methodologies to have “won,” but in my experience Scrum has made the most extensive inroads into corporate culture.  And it is chock full of prescriptive little strictures: mandatory stand-up meetings with strict time limits and precisely defined cycles called “sprints” and detailed reporting pathways between developers and business owners.  Maybe all this red tape is why business people have embraced it more than the other Agile practices.  But it presents a weird, oxymoronic message to the developers: we want to you to be free, we want you have flexibility, but you have to all these things, just so.  And sometimes the business owners can get very upset if you question this.  Because they’ve been trained, you see?  They’ve taken courses in “how to do Agile” and “how to run Scrum” and all that, and (of course) all those courses stressed that you have to do everything perfectly or else it will all fall apart, so as soon as the developer suggests that maybe we should change this one thing because it’s actually making our lives harder ... well, it won’t be pretty, let me tell you.

One of things I always liked about Scrum was that they made clear the difference between involvement vs commitment.  The traditional explanation for this is via the fable of the pig and the chicken.  Now, these days Agile folks will tell you not to use that story to explain things any more.  The first reason they cite is that people will take offense: calling someone a pig implies they’re greedy, or dirty; calling them a chicken implies that they’re cowardly.  These are, of course, human metaphors that we’ve placed on those particular animals, and also they have nothing to do with the actual story.  But people won’t hear the message, they point out, if they’re hung up on the words used to deliver it.  I would probably say that people will look to any excuse to get offended, especially if it gets them out of following rules, but I’m a bit more of a cynic.

The story points out that, in the context of preparing a breakfast of eggs and bacon, the chicken is involved, but the pig is committed.  This is a very simple concept to grasp, and the analogy illustrates it perfectly, but, yes, yes: let us not offend anyone.  I would be fine if this first reason were the only reason that modern Agile advocates had dropped the pig and chicken story: that would just mean that they had replaced it with a different analogy that perhaps involved more noble animals, or fruits, or something.  But, no: they’ve started to question the whole concept.  See, the original point of pigs and chickens was to point out to the business people that it wasn’t particularly fair (or, you know, sensible) for them to set deadlines for how long something would take.  They weren’t the ones doing it.  The developers have to actually accomplish the thing, and they know how long it should take (even if they’re bad at estimating that for other reasons, which are happily addressed by other Agile practices).  The business owners are involved, but the developers are committed.  This not only stresses to the business folks that they don’t get to say how long something takes, but it also stresses to the developers that, once they say how long it will take, they’ve made a commitment to getting it done in that timeframe.  These are all good things.

But not so, says the Updated Scrum Guide.  Those poor business people shouldn’t be made to feel like they can’t dictate timelines.  “In some cases these people were key project sponsors or critical system matter experts. These are individuals who, while possibly needing some education and guidance from a Scrum Master, can be critical to the success of a project.”  If you’re not familiar with how to translate business bullshit back into English, this means “we want the business people to feel important, and they don’t like it when we try to put restrictions on them, and if I say it this way it’ll make you think that you developers are actually gaining something, rather than that we’re just caving in and letting the business people run roughshod over all we’ve built.”  The thing I always liked about the Agile practices was that they were pretty balanced in terms of business vs development.  They said to the developers “we want you to feel respected and like your creativity is valued, and you should be in control of what you produce and the quality of your work.”  But they also said to the business side “we want you to feel respected and like your market acumen is valued, and you should be in control of what gets produced and how viable it is as a product.”  See? everybody is respected equally.  When you start breaking down that balance, bad things happen.

And maybe business people feel empowered to just set some processes up because it sounds good, or because it looks official, or maybe, like most other humans in workplaces, they just like telling other people what to do.  And maybe those processes actually slow things down instead of making them more efficient.  And maybe the developers feel like they can’t speak up any more—it’s no longer the case that they’re the ones who are committed because everyone’s committed now—or maybe they do speak up but they’re ignored because setting up workflow processes ... that’s above your paygrade, don’t you know.  And gradually, slowly, everything goes back to the bad old ways when we spent way more time talking about getting things done than actually doing things.

Doesn’t feel very agile, does it?

I know they don't sound the way I planned them to be ... but if you wait around a while ...

Well, the computer setup is going fairly well ... but not well enough that I have a longer post for you this week.  Still, despite the work dragging on, I can safely say that things are better than they were before I started ... before the machines started being flaky, even.  So I’m well enough satisfied with the progress, even if I feel a little bad for slipping on the posting schedule.  But that’s the way it goes sometimes.

Next week will be better, I can just feel it.