There are a lot of things people writing software do in the world of bits that don’t have easy analogs in the world of atoms. Sometimes it can be tremendously clarifying when one of those things gets a name, as for example when Martin Fowler invented the term “refactoring” to describe modifying a codebase with the intent to improve its structure or aesthetics without changing its behavior.
There’s a related thing we do a lot when trying to wrap our heads around large, complicated codebases. Often the most fruitful way to explore code to modify it. Because you don’t really know you have understood a piece of code until you can modify it successfully.
Sometimes – often – this can feel like launching an expedition into the untamed jungle of code, from some base camp on the periphery deeper and deeper into trackless wilderness. It is certainly possible to lose your bearings. And large, old codebases can be very jungly, overgrown and organic – full of half-planned and semi-random modifications, dotted with occasional clearings where the light gets in and things locally make sense.
A refactoring expedition can serve very well for this kind of exploration, but it’s not the only kind. As a trivial-sounding example, when trying to grok a large mass of older C code one of the first things I tend to do is identify where ints and chars are actually logic flags and re-type them as C99 bools.
This isn’t refactoring in the strict sense – no code organization or data structures change. It can be very effective, though, because identifying all the flags tends to force your mental model closer to the logic structure of the code.
Another thing I often do for the same reason is identify related global variables and corral them into context structures. (Note to self: must find and release the YACC mods I wrote years ago to support multiple parsers in the same runtime.)
For a clearer example of how this concept is different from refactoring, consider another common subtype of it: adding a small feature, not so much because the feature is needed but to improve and verify your knowledge of the code. The inverse happens – I’ve occasionally gone on exploratory hunts for dead or obsolete code – but it’s much less common.
I think we need a word for this. I spent a significant amount of mental search time riffling through my vocabulary looking for an existing word to repurpose, but didn’t find one. My wife, who’s as lexophilic as I am, didn’t turn up anything either.
Therefore I propose “explorify”, a portmanteau of “explore” and “modify”. But I’m much less attached to that particular word than I anm to having one for the concept. Perhaps one of my commenters will come up with something better.
Sample usage:
“I was explorifying and found a bug. Patch enclosed.”
“Yes, I can probably do that feature. But I’ll need some time to explorify first.”
“No, we probably didn’t need strictly hex literal recognition there. I was explorifying.”
Hrm. Not sure I have a better solution, but “explorify” doesn’t carry the sense of archaeology that the concept seems to demand.
>“explorify” doesn’t carry the sense of archaeology that the concept seems to demand.
True, but the through-darkest-Africa-with-gun-and-camera vibe seems a reasonable substitute.
I propose redd up from “redding up a room”. If I remember correctly (probably from Peg Bracken), redding up falls somewhere between actually cleaning and mere cosmetic tidying.
“Redding up” isn’t intuitively obvious, but neither (as far as I can tell) is “refactoring”..
>I propose redd up
The only people I know of for whom this is live use are Amish, Mennonites and their immediate neighbors in central Pennsylvania. Which kind of messes it up for me – my brain keeps generating an image of a programmer with a Plain People beard and a flat hat and going *TILT*.
I’d swear that there’s some sensing technique in the real world that uses a small explosive to detect structures in the ground, but I can’t seem to Google it up. But that’s what this reminds me of, some sort of highly invasive reconnaissance measure, when you really really want to know what’s going on and don’t mind doing a bit of damage in the process. (Of course, our damage is one “git reset –hard” away from being magically undone, but hey.)
>explorify
maybe it will grow on me but so far my brain makes associations with verbs like simplify, beautify, ubuntify, … these seem to indicate a e resulting state : make something more simple, more beautiful, more ubuntu-ish, …
and that doesn’t seem to work with explorify – (make something more explored ? — doesn’t sound right). But perhaps I’m missing something because I’m not a native speaker.
perhaps “grokify” works ? modify something (eg a program) so that the end result is that you grok it (and both you and the program have been modified)
At my job we call a similar concept “immersion”. A new dev joins the team, gets an immersion task in order to do something low-important, low-risk while getting acquainted the code. Or, one immerses in another team’s library in order to build a service based upon it.
I sometimes use “exploriment” in similar situations.
The “ify” suffix usually means to make something be in a particular state. “Clarify” means to make something clear, “purify” means make something pure. So I don’t think you are making the code in a state of exploring, you are rather engaging in exploration to determine its state.
I like H’s suggestion — exploriment.
logical seismology, code seismology or algorithmic seismology
You’re dropping small explosives into the logic stratum to intuit elements of its underlying structure…hopefully without triggering a collapse.
I believe the concept has merit enough to deserve a name, but I don’t like the name you’ve chosen. In trendy web-2.0-ese “explorify” sounds like either a crappy web startup or the act of making something explorable. I think “exploriment” as has been suggested in other comments is better.
Pre-C99 code? You’re not an explorer; you’re a paleontologist.
Explorimod.
Explorify obviously means “make explorable” or “make like exploration”.
underpify?
I came to this thing and it was derp… so I looked through it and thus it started to be not derp anymore, so I had underped it. In order to make dang sure that I knew it better than derp, I made some changes, so now it is underpified… at least for me.
Eric,
Why are you not happy with the straightforward “Experiment”? It seemed to work fine in all your example sentences.
Screw that, actually. I officially second “exploriment”.
BTW, on the whole concept of refactoring and its parent concept of software agility, it seems to me that it is becoming one of those buzzwords that has taken on almost no meaning because of its isolation from its original concept. “Refactoring” has come to mean “change the code” though of course the OP’s definition is precisely correct.
At the heart of the concept of refactoring is high coverage regression unit tests. It is only with a reliable set of high coverage unit tests that you can comfortably make large refactoring changes and remain confident that your code does “retain the same functionality.” And at the heart of high coverage, high quality unit tests is the concept of dependency injection and other related inversion of control patterns, so that functionality can indeed be really isolated to the unit (and pieces are sufficiently decoupled to allow refactoring.)
My practice when digging into an old piece of code is to start writing unit tests, and my initial refactorings are almost ALWAYS to do with making the code more testable. Of course that is super hard to do with C programs because they have a pretty limited language support for the types of changes you need to make, but there are certainly things you can do. (And in fairness I very rarely look at C code these days.)
FWIW, C# with its reflection capabilities, can be made extremely testable (as I am sure is true of other languages with reflection like abilities.)
> my brain keeps generating an image of a programmer with a Plain People beard and a flat hat and going *TILT*.
so all i need is the hat to make Eric’s brain go *TILT*? interesting, noted….
:-D
I am not enamored of “explorify” either. It is somehow not indicative of what you’re trying to do. Showing my age, but the word that came to me was reconnaissance, which led to long range reconnaissance patrol (LRRP or verbalized as lurp) from the Vietnam era.
See “The Siege of Firebase Gloria” with R. Lee Ermey, as USMC Force Recon rather than Army LRRP. Close enough for gov’t work. :-)
Isn’t that what you’re doing, a reconnaissance of the code?
Why not lurp your code?
> Why not lurp your code?
+1 on this idea.
Valid alternative spelling “lrrp”, from the backronym “Low Risk Rconnaissance Programming”
Explorify does sound a bit like a new-fangled social media terminology. That’s how it struck me initially before you went on to explain the term.
> Valid alternative spelling “lrrp”, from the backronym “Low Risk Rconnaissance Programming”
I like it, but I can’t read it without thinking “I am Lrrr from the planet Omicron Persei VIII” and reading it in that voice.
Thank you, John. The more I think about it, the more some derivitive of reconnoiter seems to be the most fitting to the purpose.
$ dict reconnoiter
cheers
How about “probification.”
Sorry, couldn’t help myself.
Perhaps some play on “vivisection” or “dissection”? Naturally to be done in the finest of Mad Scientist traditions, complete with maniacal laughter and massive scissor switches.
— Foo Quuxman
Continuing to play on the “lrrp” idea, sometimes when you poke around in the code, it pokes back –
compile.... run.... COREDUMPmucks about in the codebase for an eon or two, discovers an obscure place where a pointer to that long is used to store the address of a trampoline function, completely unrelated to its use elsewhere as a flag....So this kind of programming is best done wearing your notional Kevlar, and bringing your virtual Mk 1911A.
One of my “alternate” job titles I’ve used for many years is:
“Software Archeologist and Micro-surgeon”.
It is not so much exploring, but mapping or otherwise cataloging what is found when you start going places or peeling back layers. And doing small changes and or clean-ups so that things can be safely modified and put back.
I have to do enough Archeolo to get the Gist.
With dead code would it be Archeulogizing?
Yes, thanks Ken, that was the Google word I was missing. A seismic shot is what I was going for.
Mutalyze.
>Mutalyze.
Denotatively good, but sounds too much like “mutilate”.
Hello everyone, I love the term. I’m going to use it, Explorify, it’s catchy.
I think I can apply it to more than code, isn’t like kinda like a mixture of different code?
I
Sorry all, I meant “isn’t life like a mixture of different code?”
Mutilate is exactly what some code needs.
Hmmm
dissection and exploration – explorisection
vivisection and discovery – vivicovery
or maybe just plain ol’ exploratory surgery. Seems to come the closest.
Dangit, now I’m going to be pondering this all night long.
Ponder and refactor – ponderfactor – and comes with a bonus pun – pontefract (broken bridge)
Archeology & construction – archeostruction
Surveygery
It may not be too meaningful, but what about “codeegery”, “codeeging” and “codeege”
How about ‘revision’? Not geeky enough?
> How about ‘revision’? Not geeky enough?
I think that term already has a technical meaning in version control systems. So it would be ambiguous or confusing, possibly both.
>“isn’t life like a mixture of different code?”
What? Like, life is a mixture of genetic code?
So… “I need time to fu.. uh… screwify this code.”?
The problem is that I keep seeing “screwify” as “screw wifey” and wanting time to “fuckify the code” isn’t something I’d want to explain to a manager or client.
Nevertheless, the concept under discussion is pretty much: “I need time to fuck around with the code.”
Although I wouldn’t put it that way in the project plan.
If you are going to add your little bit, “Zygotify” would sorta mean the same thing and also avoid trouble with HR.
“…that term already has a technical meaning in version control systems. So it would be ambiguous or confusing, possibly both.”
I don’t think so…you would say, “I’ve been revising that code…”, certainly better than ‘screwify’.
rehacktivate the zombie code?
I admit that almost anything would be better than “srewify”.
However, not only does “revision” already have a technical meaning in version control, “revising” already has a common meaning: changing or improving; that is not the concept that we are trying to label.
“lrrp” / “lurp” is elegant but for obscure reasons and I doubt that it would catch on.
I think that “explorify” and “exploriment” are the best suggestions so far.
“Reconnaissance by fire.”
I have to say that “explorify” does not sound to my ear like a portmanteau of explore and modify. It sounds like a twee version of explore – or worse, like a market droid’s attempt to be twee. “Spelunking” is close but lacks the sense of making active modifications in order to better understand the thing – and it’s already used in that more passive sense. I might go spelunking in a manual, or Chemical Abstracts, or Beilstein Online.
Maybe “tomb exploring” or “tomb raiding” for the sense of rough-hewn archeology: Breaking in, finding the dead bodies, and mapping and avoiding traps after the manner of Indiana Jones or Laura Croft.
“Reconnaissance by fire.”
Sort of like Ms Boxer’s test suites; shoot at everything and see what shoots back.
I’ve use the same term as TZ uses above: “Software Archeologist”. I just joined a company where I’m the caretaker for code that has been mangled by dozens going back 20 years. It’s a maze of twisty little passages, all alike.
So I put on the Indiana Jones fedora and go code spelunking. Code spelunking is not just a passive activity, you must leave a visible trail to get back out, and perhaps leave behind active markers so you can map where you’ve been once you get out. And sometimes, you must blast passages as you leave, so as to seal the horrors within.
lurrp it is for me… it’s nice, and has all the meaning within… loved the backronym.
Apparently this word has an opposite: gandalfing. It means to pore over the documentation in search of an answer that will immediately let you grok the code/write a solution, on the first try. The image is of Gandalf going through the archives in the library at Minas Tirith in search of the scroll of Isildur.
Not a programmer, just like word creation, especially acronyms, so I like the lrrp=)
I agree w/ Jessica, without your explanation I would think you had made the code explorable, although I do like explorimenting
From your examples I would think the term ‘audit’ could apply & you don’t need to educate your readers on the meaning of the new term
@ esr
I thought of this before I read the comment by tjs, which included this idea: “active exploring” as opposed to “passive exploring”. Of course, it isn’t a single word. (I do like “lrrp” or “lurp” if you can get it accepted.)
I’ve been thinking about the idea itself. If you are not the owner or a dev in the project, does the concept generally imply that you keep/apply the modifications? Consider your first usage example…
“I was explorifying and found a bug. Patch enclosed.
I would think that normally, the recipient wouldn’t care how you found the bug, but the word “explorifying” suggests that you may have also modified the code in ways not related to the bug. If you did want to submit these modifications, would you generally do it in a separate patch?
As John Bell suggested, changing a long to a bool can sometimes have unexpected results. Is it common for unit tests to exercise every code branch, rather than just functionality?
>(I do like “lrrp” or “lurp” if you can get it accepted.)
Yes, I like that one myself. That and Dennis McCunney’s suggestion of “delve” over on G++ seem to me to be the best of the alternatives so far.
>If you did want to submit these modifications, would you generally do it in a separate patch?
Yes, because in general it’s good etiqutette to submit separate bug fixes and enhancements separately.
>Is it common for unit tests to exercise every code branch, rather than just functionality?
Unfortunately, no, it isn’t. Even knowing what coverage achieved is hard, let alone achievoing that kind.
John’s story ia a good horrible example of a couple things – why you have to be careful when explorifying and why deliberately breaking the assumptions of C’s type system is bad.
> Therefore I propose “explorify”, a portmanteau of “explore” and “modify”.
Explomod?
Although that sounds to me more like “to rig with explosives”.
I love the “immersion” one. This one popped into my head:
destraction
As in : an antonym of abstraction
>destraction
Nah, people would just read that as a misspelling of “distraction” or “destruction”.
Reconnoitre is the word that came to my mind, but Gary got it first. The old explorers would leave marks on trees so people could find the way.
Trail-blazing sounds like the exact analogy to what you were doing by “explorifying”. So maybe “blazing” the code, since your little markup changes (ie, the int to bool conversion) exist to illuminate or emblazen the code for greater understandability.
>So maybe “blazing” the code, since your little markup changes (ie, the int to bool conversion) exist to illuminate or emblazen the code for greater understandability.
Aaaaand this is why I don’t kick even kooks like Ted Walther off my blog. Every once in a while the perfervid recesses of their brains generate something interesting and valuable. “Blazing” is pretty good.
I’ve been thinking “rif” after the military acronym “RIF” for “reconnaissance in force”, which captures the concept pretty well. Problem is that word doesn’t form unambiguous derivatives.
What about codegeering? (code + engineering)
Or codereanging? (code + re-arranging)
Or recodeoiter (reconnoiter + code mix)
How about “fossick”?
Australian slang for “to pick through or rummage through something”.
It carries a mining/geology connotation, such as when you dig through tailings and other cast-off waste in order to eke out the last bit of valuable material.
>How about “fossick”?
I’d like it, except that in the British usage I’m familiar with it seems to have some connotations of pointlessness and misdirected effort. Which, I see, don’t show up in the on-line dictionaries, so it might be that I’m wrong about that. Or that those dictionaries aren’t very good. Either is possible.
“Fossick” is no good. Fossicking is exploration through a collection of objects for some item of value. The rest of the context is discarded as dross, or ignored as irrelevant to the present need. As for instance, searching through a semi-indexed mass of parts and supplies for an item that meets a need for which it was not intended or allocated.
In the code exploration ESR describes, the whole structure is of value, with the possible exception of some dead code.
I note that though they don’t have a name for the practice, this practice is the formal introduction to LibreOffice: their Easy Hacks list, where you can get to know the (planet-sized) codebase by doing some useful cleanup task.
Similar to TZ I’ve been putting “Systems Archeology and Process Anthropology” on my resume for a while now.
This follows from Verner Vinge’s term “programmer-archeologist” in one of the books in the Deepness in the Sky series, in which programmers–working on centuries old systems (imagine what a Linux/Unix based system will look like in 200 years if it’s never replaced)–routinely had to dive deeply through layer after layer of system code to figure out WTF was going on.
Progeology? (prog-e-ology)
RIF also stands for Reduction In Forces.
Explorify is way too twee, in my opinion.
It seems to me, that this focus on archaeology is missing a more useful point of view. The code being refactored is like a living creature that has problems, whether of the genetic, disease, or accidental kind. The refactor-er is like a surgeon, making patches/fixes/changes to a patient, so that the patient can live a happier/easier/fuller/more-productive life. My thinking is that, looking for catchy phrases with that analogy might make more sense, for what is actually being done.
@Leonard:
According to Mr. Raymond the point of the exercise is to gain an understanding of the codebase, not necessarily (at the time) to fix it. It might not even be any sicker than large projects normally are.
I like exploriment.
How about good old ‘poke’?
Several uses that kind of fit.
‘Poke’ as in ‘poke around’ like rummaging through an attic full of cruft.
‘Poke’ as in being poked and prodded when a doctor examines you.
Or ‘poke’ as in BASIC. Heh.