Eschewing jargon…

As longtime readers may remember, I suggested a long time ago that if/when VB added refactoring we might not call it “refactoring.” This immediately raised a hue and cry about how I was saying that VB users were “dumb,” how I was turning my back on an industry term that “everybody knows,” how this was just another example of how out of touch we were. I tried to turn in a good defense, but in the end it didn’t really matter, since first refactoring was cut and then it was an add on, and the add on uses the term “refactoring.”

I was reminded of this when I read Chris Williams – someone who would not be described as a low-end VB programmer – talking about how he finally managed to connect the abstract term “refactoring” with the basic concept of “cleaning up your code.” This much more eloquently states what I was trying to get at way back when, which is that what I find annoying about monikers such as “refactoring” is that they often taken a simple, straightforward concept that most people are already familiar with (“cleaning up your code”) and dresses it up in a funny hat to make it look like something new and special. This works well for:

  • …the originator of the moniker, because now he gets to be called “the father of refactoring”, which sounds very impressive.
  • …the author of the book on refactoring, because “Refactoring” or “Refactoring Explained” sounds more impressive than “How to Clean Up Your Code.”
  • …the lecturer on refactoring, because a talk called “Refactoring” or “Refactoring Explained” sounds more impressive than “How to Clean Up Your Code.”
  • …the consultant, because saying “well, you really need to refactor this code” sounds more impressive than “well, you really need to clean up this code.”
  • …the tools vendor, because saying “Now Supports Refactoring!” sounds more impressive than “Now Helps You Clean Up Your Code!”

Who it doesn’t always work well for is:

  • …the guy who just wants to clean up his code but doesn’t really have the time or inclination to invest much time in learning the latest jargon for something that he’s probably already doing today.

All that being said, I freely admit that jargon is often a necessary evil. After all, if you want to talk about a particular concept, you still have to name it. What bugs me is the way that the jargon often starts to take on a life of its own, until the original useful idea that it refers to is almost buried under a pile of formalization and people start to lose sight of the simplicity of the original concept. Maybe there’s nothing to be done about it, but that doesn’t mean we still won’t look for a way out of the dilemma…

15 thoughts on “Eschewing jargon…

  1. SpookyET

    Basically, "refactoring" sounds polite. "Clean up your code" implies that you made a mistake.

    Speaking of refactoring, do you know why there is not a language service that supports refactoring in Visual Studio? Each language binding must write their own refactoring from scratch as oposed to consuming an API.

  2. Louis Parks

    I think that clarity is the most important objective. It seems to me that using industry standard terms, as odd as they may seem, is a better idea than going off on your own. Why? Simply because now there are two different ways to refer to the same idea. What good is that, if your goal is to make things easier to understand? Example of my beefs with VB doing just this – industry term: static, VB term shared; industry concept: method/function; VB concept: sub AND function; industry standard: use parens when calling methods/functions; VB (pre .NET): use parens with "call" or if you want the value back. Ugh! Why couldn’t they just conform to the rest of the industry? I know it is more than a little naive to pretent that there is a lot of standard-ness among the many programming languages, but at least when forging ahead we can stick with widely adopted things…and the term "refactor" is definately widely adopted.

    Specific to refactoring, I take issue with "cleaning up your code" because that isn’t, in my estimation the only thing that refactoring does. If you extract a piece of code that is in a single use place to make it available for many callers, is that "cleaning up your code"? I’d say not. I’d say it is refactoring or repurposing or making your code more reusable. Cleaning up implies there’s a mess. If the original condition under which a piece of code was written was that it was single use, there is no "clean up" involved to make it a reusable piece of code…in my mind at least.

  3. RichB

    Refactoring is the correct term for this activity.

    I remember code where one of the developers modified a .bat file I wrote and added the comment "Factorised." along with the obligatory date and initials. This was before anyone on the team had heard of "refactoring" as a discipline, yet that’s exactly what the developer had done.

    SpookyET: VS.Net Refactoring isn’t a language service because it doesn’t operate on the CodeDOM. It operates on a quasi-AST which is potentially invalid code – ie code which will not compile. Coming up with a language independant, non-compilable, quasi-AST will take a couple of iterations of VS.Net!!!

  4. Robert Conley

    "Cleaning up your code" is the definition of refactoring. As Fowler and other shown that "Cleaning up your code" is a specific area within computer science that can be studied and expanded upon.

    "Cleaning up your code" isn’t a new idea but the fact there are steps you can take to do this reliably and consistently and that these steps can be collected, analyzed and published is what is new.

    When people do that they put a name to it and in this case it is refactoring. If you want to learn more about it you will find books about refactoring not "Cleaning up your code".

    But at one time encapsulation, inheirtance, and other OO concepts were not known. Or further back you can take commonly used computational steps and called them algorithms or even further back when a computer was a person who sat with a machine and performs mathematical operation over and over again from a table of numbers.

  5. Phil

    <em>the guy who just wants to clean up his code but doesn’t really have the time or inclination to invest much time in learning the latest jargon for something that he’s probably already doing today.</em>

    Experience has taught me that those who can’t be bothered to keep up to date with what’s going on in the software development world are usually the ones who are happy to bang out crappy code and never clean it up.

  6. Pingback: Blogus Maximus

  7. SpookyET

    Louis Parks: X-Develop ( has a language engine and is able to refactor across languages, and it is at version 1.0.1. X-Develop is a very interesting IDE. For Java, it even has back-in-time debugging. So, it is possible.

  8. Louis Parks

    I didn’t say it wasn’t possible. I actually don’t have an opinion on the matter. I was just offering Paul’s explanation for why VS doesn’t do it based on what I remembered him saying a few months back.

  9. paulvick

    Louis, my comments were more directed at the general use of jargon in the industry. Once the jargon is established, however, we’ve definitely gotten the clear feedback that people would like us to use it rather than invent our own. 🙂 Many of the examples you cite also predate a real convention among programming languages – remember, BASIC has been around a long time!

    Spooky, as I said in the other entry, "Now, one could certainly imagine a world where it might be possible to share the work on refactoring across the languages, but we’re just not there yet." It’s something we’re definitely looking at for the future.

  10. Hermann Klinke

    At least it’s easier to google for "refactoring tools" than for "tools helping cleaning up your code", because you will get better results.

  11. Pingback: Blogus Maximus

  12. Pingback: Blogus Maximus

  13. Gérard Mendes

    Refactoring isn’t just cleaning up your code. Cleaning up means you have left things in a dirty state.

    Refactoring is changing the structure of the code to better fit the design you want. If the design has to evolve because of a new requirement, you can refactor your code to go towards a new design direction.

    Refactoring is more about evolution than cleaning up, although continuous refactoring is cleanup indeed.

  14. Pingback: Karl Seguin [MVP]

Leave a Reply

Your email address will not be published. Required fields are marked *