This Month

Welcome to the third month of the Impractical Engineer! I’m your host and editor, Onorio Catenacci.

It’s July, a time to celebrate our freedoms and enjoy outdoor activities with friends and family. Also a time to sit indoors and read the musings of a certified (and certifiable) nerd.

A word about content. While I’ve titled it “Book Reviews Dept.” my writing in that particular section of the newsletter has always been more about drawing people’s attention to what I consider are worthwhile books and other resources. So even though I’ll continue to call it “Book Reviews” I won’t feel compelled to solely talk about books.

This month we’ve got a video review, another puzzle (with the solution to last month’s puzzle), a little bit of basic software engineering discussion, and some other goodies as well. Hope you enjoy and, as always, I consider feedback a gift so if you care to gift me with your feedback I’d greatly appreciate it!

Puzzle Dept

Puzzle

June’s Puzzle:

You are an adviser to the king; the king has acquired three magical glass flasks and he’s asked you to determine if they are all using the same unit of measure. The enchantment on the flasks is rather unusual; you can pour any liquid into any of the flasks as often as you like. But every time you pour from one flask to another you risk the enchantment being broken so you want to avoid pouring between flasks as much as you can.

If you count pouring liquid from one flask to another as a “pour” and you don’t count filling the flask initially as a pour what’s the fewest number of pours you need to determine if the beakers are commensurate (that is using the same unit of measure)? You can also assume that you can fill each flask to the rim and that no liquid is ever spilled.

First fill the “2” flask. Pour from the 2 flask into the 10 flask. Fill the 2 flask again four more times each time pouring into the 10 flask. One of three things will happen.

A.) The 10 flask is filled to the brim. 2 and 10 are commensurate because five times the 2 flask is 10.

B.) The 10 flask overflows. 2 and 10 are not commensurate.

C.) The 10 flask is not filled to the brim. 2 and 10 are not commensurate.

If scenario C comes to pass then you’ll want to fill 10 to the brim. Otherwise, pour the 10 flask into the 5 flask. Then empty the 5 flask and pour the rest of the 10 flask into it. Again, the same three possibilities are present. If A comes to pass then all three flasks are proven to be commensurate. Hence the answer is that seven pours (between flasks) are required to check if the flasks are commensurate. If you came up with a different solution or if you think I’ve solved this wrong, please let me know!

July’s Puzzle:

“The shortest distance between two points is a straight line.” That particular bit of geometric observation is credited to Archimedes, the ancient Greek polymath and scientist. I was a bit surprised to find out that he’s credited with saying it; I had always expected it to be something from one of Euclid’s Elements before I looked up the details of the quote.

This month’s puzzle poses a slight variation on this ancient bit of geometry. For the following discussion, apologies in advance to any mathematicians who may see this because I’m going from my memory of high school geometry.

The line between two points a and b is signified ab. Now if there is an impenetrable barrier between a and b (let’s say it’s another line called cd), what is the shortest distance between a and b? Remember you cannot directly connect a and b. For sake of easing the solution of this problem you can make some assumptions about the geometry of ab and cd.

Coupling

Along the same lines as the excellent talk I’ve linked in my “Book Review” this month, I’m going to try to explain some basic software engineering terminology.  I’m always interested in learning more and exposing my ignorance to the public is a great way to learn. The (relatively) old saying is true; if you want the correct answer to a question, post the wrong answer online and you’ll have the right answer in 12 seconds flat.

I ran across the notion of “coupling” in Steve McConnell’s seminal work on software engineering Code Complete.  The term coupling was coined by Larry Constantine who was the originator of several terms which we use in discussing code quality and software engineering. 

I can guess that probably a few of my readers will be familiar with the term but I’ll define it anyway just to ensure we all have the same understanding of terms.  Coupling is a way of discussing how interdependent two parts of code are.  You might think of it as a shorthand way of saying—if I were to move this (function/module/class) to another code base, how much other code would I need to take along with it for it to compile?

I don’t know about anyone else but a concrete example usually helps me to grasp a concept so here’s some pseudocode to help illustrate my point:

fn CalculateSalesTax(grossSales: float) : float

{

grossSales * salesTax

}

Again just to ensure we’re all understanding things the same, this is a function that takes a gross sales amount as a floating point value and returns the sales amount with sales taxes included as a floating point value.

If we were to move this code to a different source file, it’s pretty straightforward except for one thing. We need to know the definition of salesTax.  The definition of CalculateSalesTax is coupled to the definition of salesTax. It shouldn’t be terribly hard to fix this particular bit of code so the coupling is relatively loose.

Now let’s consider what might be a slightly more realistic scenario:

fn CalculateSalesTax(grossSales: float, state: string) : float

{

grossSales * getSalesTaxRate(state)

}

Now if we were to move this code to another source file we cannot simply move the function in isolation; we also need to find the definition of getSalesTaxRate and move that too.  Slightly less loosely coupled but nothing insurmountable either. 

It’s worth noting that it’s not just an issue of needing to pull a definition across.  Most languages support constants–that is names bound to values that are usually visible to every part of the code but are unchangeable.  This is extremely useful for things such as error codes and things of the like.  But consider that the only difference between a global variable (bad) and a constant (good) is that the former is writable anywhere in the code but the latter can only be read and not changed. They’re both forms of coupling but most experienced software developers avoid global variables like an IRS audit and with good reason.  It doesn’t take many global variables to make a code base incredibly hard to maintain. 

Now if you look up coupling on Wikipedia you’ll see there’s a whole taxonomy of types of coupling involving code.  And that’s important to be aware of.  While avoiding coupling is a good thing like any good thing it can be taken to unhealthy extremes.  In many ways, avoiding coupling is the opposite of “don’t repeat yourself”.  That is, to avoid coupling we’d need to repeat certain parts of the code over and over. We use coupling when we use library routines provided by a language or an OS. We’re coupling our code to their implementation of something.  It’s a rare case when this becomes something we need to concern ourselves about so we mostly ignore the coupling and get on with our jobs. Again, sometimes decoupling code will lead to duplication. As far as I know there’s no golden guideline on how much decoupling is good and how much is simply creating extra code in a misguided effort to avoid any coupling.