When All Else Fails... Where's the Manual?

How many times have you purchased a product and it required some sort of assembly? You try to put it together only to find you have extra parts left over. As a last resort, you look for the manual. What about when you have to repair it or modify your purchase? Where is the manual?

Concerning software development, if you have a piece of code...a class, a library, or a database table and no one knows who owns it (a.k.a. who created it, is responsible for maintenance, and/or is the source of knowledge for that machine) and something needs to change, either moving to a new system, new feature added, etc, then you have a problem. What typically ensues is similar to what takes place on a factory floor when a piece of equipment that has been running for some time on a production line with out issue needs fixed or new functionality added. 

First, an inquiry is made to the maintenance team asking who is responsible for its upkeep. However, what is found is the maintenance personnel that once created the machine, did the upkeep, and the addition of new functionality is no longer with the company. Then, the maintenance team will review the equipment manual (think dev team documentation here for this analogy). If there is none (which unfortunately is the common case with software that is produced by many dev teams), the team has to consider a few options.

Should they reverse engineer the machine and create a new one? What about simply making the needed changes to the current piece of equipment and risk breaking it? As you know from experience or can imagine, each option has its pros and cons. Yet, wouldn't it be better to have some documentation available to assist? This is why, in my view, documentation is so important when creating software.

Do yourself and others a favor and document with both informative comments in your code as well as external documentation explaining the business rationale as well as a description of your interfaces and objects. 

Niall Ferguson, author of The Square and the Tower, on TWiT's Triangulation show

Just listened to Niall Ferguson, author of The Square and the Tower, on TWiT's Triangulation show. Yet another reason that the Humanities in general and History specifically is vital in any well rounded education.

Newport on the Levee and the Old Netscape Browser Logo

I was running across the Purple People Bridge from Cincinnati, OH to Newport, KY and noted the digital sign that they have posted on the KY side of the bridge. I was quickly struck with the realization that the Newport logo reminded me of something familiar yet old. After I moment I remembered. The Newport logo reminded me of the old Netscape web browser logo.

Newport on the Levee Sign	Old Netscape Browser Logo

All is well with your approximate existence, mate.

In my Business Programming class that I teach, I was putting together a demo for the students to show the precision, or lack thereof, of certain numeric datatypes. The language is VB.Net. Here is the comment that I have in the code:

'To check floating point division (with Single, Double, and Decimal datatypes), take the quotient and multiply it with the divisor to get a very close approximation to the numerator.

'Why an approximation? "Squeezing infinitely many real numbers into a finite number of bits requires 'an approximate representation.'" (Emphasis mine)

'See https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
It was with that thought that I realized, I am not sure that I like that it is an approximation. Yet, we must and do live with approximations all day long. This came to light to me back in 2007 when I started to really keep track of my nutrition. Right away I realized that when recording my intake for each meal and snack the data are not exact but rather a range of values. For example, when you eat an apple (medium 3" diameter (182 g)), is the caloric intake always 95 calories? No. Is it ever? Occasionally. The point is, on most occasions we make decisions based on approximations and not exact amounts. Yet, these estimates are good enough for most of life in time and space. If you are a fan of Crocodile Dundee, remember the exchange between he and Sue when discussing his age?

(SUE) How old are you?
(MICK) Dunno. What year is this?
(SUE) You don't know?
(WALT) Time doesn't mean much up here.The Aborigines don't have calendars.
(MICK) I was raised by the local tribe.I asked one of the tribal elders when I was born, and he said,"In the summertime."

Of course, this did not mean that Crocodile Dundee was not born on a specific day, but rather he didn't know what day that was on a Gregorian calendar. Yet, he lived day-to-day the same as if he had known the exact date. 

Mind you, with computer languages and floating point datatypes, there are safe guards so you can rest assured all is well with your approximate existence.