Author: Kyle Cordes

How Not To Shoot Yourself in the Foot with Change Control

As anyone with experience in a large firm knows, change control procedures (and “change control boards”) are a common fixture. Change control mechanisms (such as requiring extensive documentation, signatures, meetings, checklists, approvals, etc.) have obvious benefits, but they also add inertia, increasing the cost of change. This refers to both dollar costs (meetings aren’t free), and to inaction by employees who find it not worth the effort to a desirable change approved. The net result can be that bad procedures, features, documents, etc. stay in place, to the detriment of the organization.

Thus, I will frame Kyle’s Guideline on Change Control:

The “weight” of your change control system should be, at most, proportional to how good your product / processes are. If things are really bad, fix them *first*, while it’s easy, and then *after* that add in the obstacles to change.

Unfortunately, this ubiquitous alternative procedure:

  1. Notice things are bad.
  2. Add change control mechanisms that make it hard to fix them.
  3. Avoid changing the things that are bad.

is actively stupid. (Of course, maybe your problem is that things change too much… in that case, the first thing to change, is to make it harder to change.)

One URL per page

A few weeks ago I was working on a web site that wasn’t getting as much attention from Google as the site owner expected.  One (of many) issues was that for every “interesting” page (those that had link-worthy material), there were at least three URLs for that same content. Depending on how the user navigated the site, they’d get to a different URL.

I pointed out that this is a Bad Thing, since distributing the incoming links across those duplicates would decrease the Google-worthiness of each… but hadn’t had time to write up the detals.  Today I was thrilled to see this detailed writeup of the phenomenon and this one about how fix it.  I’ve done the same thing in the past, but never written it up.

If your site has this “feature”, and you would prefer it gets more traffic, fix it.

Indentation as Block Structure – HAML instead of RHTML

When I starting with Python sometime in 2001, I was briefly frustrated by the intentation-as-block-structure syntax; but after a few weeks I found it  natural. Its most obvious advantage is that it avoid the duplication between indentation and braces / keywords. Yet this kind of syntax has not become popular outside of Python.

Today I saw an interesting use of it “in the wild”: HAML, an HTML templating mechanism for Ruby on Rails. I haven’t used HAML (and may not, since at the moment we have only some sample projects using RoR, nothing in production), but from the tutorial it appears to be a very tight (indentation-based) syntax for HTML templating. I’ve encountered a Rubyist or two who disdains the Python syntax – I wonder if that similarity will limit HAML’s adoption.

High Level Assembly Code?

A while back I needed to reverse the order of the 4 8-bit bytes in a 32-bit word, in some Delphi code. I worked out a way to do it with bit shifting, read the docs for a few minutes, and got something to work with AND, SHL, SHR, and some $FF constants. Later I encountered (on a usenet post which I can’t find at the moment), this implementation, which consists of some Delphi cruft around a single assembly statement:

function Swap32(aLong: Longint): Longint; assembler;
asm
BSWAP eax
end;

This is an unusual occurence: the assembly code is shorter, simpler, and more obviously correct (see this explanation of BSWAP), than the high level language implementation. Hmmm.

$200 -> Inno Setup

I’ve been using Inno Setup to build installers for a variety of projects for 5+ years, for both personal and commercial projects. Inno is very high quality software, extensively debugged and robust. I prefer it to the other install-builders I’ve tried, including NSIS and various commercial packages (some of which are truly awful).

When I saw this discussion on Joel’s discussion boards, I realized that I too had benefited greatly from Inno yet offered nothing in return. So today I sent $200 over, and I encourage anyone else using Inno to support the project also.

National Geographic Chartjunk

National Geographic generally has lots of high quality content, with very high production values and attention to detail in layout and design. Keeping that in mind, I noticed this chart, below in the Feb. 2007 issue on page 56:

This, sadly, is an example of what Edward Tufte calls “chartjunk”. It contains extraneous elements that don’t help:

  • The United States label seems quite superfluous.
  • The mileage scales (including a separate scale for Alaska!) are completely useless in the context of this chart.
  • The “Panic! Panic!” red color is unhelpful; the chart could convey its data more clearly with a range of colors to show the data, rather than only values of red.

Yet it is missing the obvious details that would help:

  • There is a color scale, with the midpoint marked numerically, but no indication of the range. The middle of the range is 494 “deaths per year per 100,000 adults 35 years and older”; that is marvelous specificity, but we aren’t told whether “Low” is 490 deaths per year or 4 deaths per year. Is “High” 500 per year, or 2000? Is the scale linear, logarithmic?

Unfortunately, the meta-message is to not trust this chart – to assume the person showing us this chart is trying to influence us by their choice of what tiny bits of data to include (the midpoint only) and the scary coloring. If it had all the data, I’d be wondering things like “why do so many more people die of heart problems in some areas than others?” rather than “I wonder if they data range is so embarrassingly small that the graph creator chose to omit it?”