Locking It In

So in an odd set of coincidences over the past few days, I've engaged in several conversations about working with legacy code. One particular thing that migrated to the top of the conversation was locking in current behaviors. Somehow those conversations all degraded into a hairsplitting vocabulary conversation. So I thought I'd capture my thoughts and share them.

Pedantic-ness

One of my great frustrations within my professional world is the degree to which we are pedantic. Collectively we vacillate between being very precise and totally vague with our language. The convenience of vagueness is that we don't have to establish a common vernacular. The problem is that it can lead to misunderstandings and miscommunication. On the other hand, pedantic arguments often lead to frustrating if not infuriating conversations about the meanings of words. I submit that pedantic-ness is wasteful. Don't be a pedant.

My Bias

I consider myself expedient. That is, I'm not much for wasting too much time. So all the pedantic hairsplitting is nonsense. This isn't really fair and I understand that sometimes you gotta stop back and explain yourself. Especially when addressing topics across cultural boundaries. We could all probably do better at the listening thing and the thoughtful consideration thing. But judgments based on unswerving or blind opinions are a nuisance to be avoided.

The Hair

So the hair that got split this week was Pin-down Test. We were discussing Characterization Testing as a component of Legacy Rescue and techniques for ensuring that we don't break existing functionality when adding a new feature to a system. I'll spare you the details as much as possible here but, the term 'pin down' was used to describe why we would characterize a system. Something along the lines of 'We are adding these tests to pin down the behavior of the system'. 

Gnashing of Teeth

Once the term pin down came out the conversation devolved into a violent agreement that pin-down testing is a thing, a good thing, and distinct from characterization testing BUT that pin-down should not be used in describing characterization testing.

Waste

So there was a protracted discussion of these things. Mostly it was all in agreement, that they have the same intent, to describe the current behavior of a system without a value judgment on rightness or wrongness. The conversation took a considerable amount of time and I categorize it as waste because it was more about egos and the need to be more formally correct (pedantic-ness) than it was about developing clarity. 

Clarification

So the result of our collective dance was this. 

Pin-downs are about dissecting code; they enable refactoring and allow us to break down legacy code and they may include a bunch of scaffolding and other edifices that are (or should be) disposable. Pin-downs are often used to identify a defect in a system and then as a sentinel to identify the resolution.

Characterization tests on the other hand are intended to be permanent additions to a test suite to ensure that there are no changes in behavior. They assume that the current behavior is the correct behavior.

Summary

So the specific issue, characterization v. pin-down results in a subtle clarification. In essence they both lock in behavior so we can tell if we're breaking things. The temporality of tests and their attended scaffolding is one of the distinguishing characteristics. Furthermore, the purposes of creating such tests are distinct variations of each other. If ever a hair was split so finely. 

My point though is, much of the discussion had at the time was a waste. Debating the use of 'pin down' in the context of characterization is just flexing. As I've read and discussed this topic over the past few days it's really forced me to focus on the meanings of these terms and then be exasperated by the English language. 

Personal Note:

Thanks to Tim Ottinger @tottinge and Stephen Cavaliere @SteveCavaliere among others for the discussion and thoughts on this particular topic

Where is Rich?

 Hey all, sorry for the delay in my posts. I was on vacation and I forgot to post that I was going away for 2 weeks. I'll be back with a post this coming Friday.

A foolish consistency...

 "A foolish consistency is the hobgoblin of little minds" -- R.W. Emerson

I used to hate that quote. I hated it because people would misquote Emerson all the time by leaving off the 'A Foolish' at the beginning. Consistency has its purposes.

I previously wrote on code being consistent in its structure in order to reduce cognitive load. That same thinking can be applied elsewhere.

Standards

Recently I've been working with my team to develop standards and processes for our organization. We're focused at the moment on identifying known standards and capturing those in one place. But in some cases, the known standards aren't written yet. This is a big problem in the sense that there are dozens of standards and keeping them consistent and well-organized is proving difficult. 

We are doing this because we are trying to create consistency across our organization. The consistency that we believe will enable us to easily automate processes. Our mission is to reduce the friction of putting code into production. 

My Personal Dichotomy

Among the dozens of identified standards we have identified are choices about tools, technology stacks, and language standards. I personally am working on the standard for Python development. 

Anyone who's worked with me before should know that I'm personally indifferent to style guides in programming. That is, I don't care what the standard is, I care that the standard exists. You'll also know I'm not a big fan of PEP-8 or the defaults in pylint. So maybe it's ironic that my standard on Python says 'start with PEP-8 and use pylint'.

Consistency Can Increase Value

I won't drag you through my philosophical arguments against the defaults. I want to talk about value delivery and speed and how any standard enables that. 

Having a programming standard that is enforceable (and hopefully auto-fixable) gives me an advantage when I code. Taking 30 minutes to setup pylint and my IDE for auto-formatting lets me stop thinking about formatting and style. Those things become one less thing I need to do before creating a pull request. Minimally I don't have a colleague checking the rules for me. Ideally, my IDE corrects the issues as I create them. That allows me to work on problems that really matter.

Not Foolish, Pragmatic

The consistency of the standard isn't foolish. We're making this choice to remove a whole realm of discussion from the production of software. We are working to reduce friction and speed up development so we can deliver more value more often. Part of that is the standard itself and how it impacts our reasoning about code and part of that is leveraging or enabling automation. Remember, it's a choice to do things consistently, the standard is mostly an opinion on correctness. Don't blindly follow a standard, understand why you have it and what you get for having it. My advice is 'steal a standard' and tweak it, but don't 'not have a standard' and find a way to automatically enact and enforce the standard.