Tag: commentary

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.)

$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?”

Hotel connectivity, with click tracking by SuperClick

I’m enjoying my stay this weekend, but the Big Cedar Resort uses click tracking software, which is unethical and unnecessary. Some details of this “superclick” tracking system are on nerdblog and swiK. There is much discussion of the system on SlashDot.

My take on this is that “don’t be evil” is good policy, and not only for Google. In addition to a very healthy room rate, this place charges $10 for every 24 hours of connectivity – a rate of $300 per month! That should be enough – they should not also sell me out for a system that “allows hoteliers and conference center managers to leverage the investment they have made in their IP infrastructure to create advertising revenue, deliver targeted marketing and brand messages to guests and users on their network.”

Big Cedar and SuperClick: I do not want to be leveraged. I do not want to be targeted. I do want to stay at a nice resort, with access to problem-free and spy-free internet connectivity.

Update: In addition to the issues above, this remarkably bad system also breaks the back button on many web sites.

I have seen the future, and it runs OSX

iPhone: Wow

It’s a phone. It’s a PDA. It’s an iPod. It’s a widescreen video iPod. It has zero physical buttons, rather the whole front is a multi-touch-screen. I’ll leave the rest of the raving to the many other sites doing a great job of that.

The real innovation of this new device is the OS. Apple has an answer to PalmOS and Windows Mobile (CE): run their real desktop/server OSX, with Unix inside, on the phone. Today’s handhelds have much more computing power and storage than desktop PCs of a decade ago, and there are enormous benefits to running a real, common OS on such a device. I’d been saying since I bought my first Palm (a Handspring, actually) than within a decade the handheld OS’s would go away.

Apple has gone first. How soon will Microsoft follow? Will Palm and RIM make to the new era at all?

(Update: Yes, the title of this post is slightly in jest. I’m serious about real OSs in handheld devices, and the iPhone looks fantastic, but Apple is very unlikely to dominate the phone market in the way the iPod dominates the tiny-media-player market.)

Iterative Delivery: Finish Something, Ship, Repeat.

I’m in the habit, and we (Oasis Digital) are in the habit, of having a lot of irons in the fire: many features in progress (in development) at a time, working a bit on each. There are good reasons to do this – for example, it helps keeps a team engaged, it avoids being “stuck” on a feature in need of customer feedback, etc.

But it is also a form of multitasking (which makes us stupid). It turns out that within certain constraints, we can deliver value to our customers much better by not multitasking, but rather by a focused approach:

  • Pick a small number of features, those most important to customer(s).
  • Bite off a reasonable small scope of each – if a feature is large (or even not-really-small), split it in to a part of finish right now and another part to put in the backlog
  • Work on them to 100% completion (delivered to the customer, done) of some useful scope
  • Repeat.

Of course, this is called “iteration” and we all know that’s like mom and apple pie. And yet… knowing something is good, is not the same as doing it.

Regarding the splitting of scope in to “now” and “later”: Some developers and teams are prone to use this as a way to not give the customer what they want. That is an abuse of the idea of iteration. Rather:

  • “Let” customers want what they want; you can’t stop them anyway.
  • Don’t try to talk them out of it.
  • Don’t try to avoid giving it to them.
  • Don’t look for ways to stall “forever”
  • Don’t look for ways to drag out the delivery of the first piece
  • Do work with them to split what they want in to a series of pieces which you can deliver iteratively.
  • Starting delivering pieces soon.
  • Keep delivering.