Continuous Delivery

One of the buzzwords that has become more popular in recent years is “continuous delivery.” The idea is that you fully automate your deployment pipeline and put a new version of your software in front of your users at least every day. If features are partially implemented, you use the Feature Toggle pattern to turn them on or off.

The value proposition is clear enough — getting your software in front of users as quickly as possible is the best possible way to get their feedback and make the inevitable course corrections that are necessary.

A more subtle value is that it greatly decreases the distance between responsibility and accountability. Perhaps I am the only programmer who has commented out a suddenly failing test rather than seeking root causes, but perhaps I am not. If, though, I knew that “it works on my machine” was going to be the lame excuse I’d have to offer for a customer-visible problem, I would be less likely to sin.

Alan Zeichick argues that useful changes can be made without affecting the user experience (or, by increasing performance, affecting them in a way that is universally preferred).  That certainly could be true on occasion, but surely the point of continuous delivery is user-perceptible change and I am not at all sure that all customers value applications whose behavior and UI are prone to frequent shifts. It seems to be fairly common in the world of retail Web sites, but for line-of-business applications, clients are very cautious about change. The behavior of a system, even if it violates some clearly-documented procedure, is generally a part of a larger process (which, in turn, often compensates for the aberrant behavior).

One doesn’t talk about training for retail Web sites, but it is a rare business application where training is not considered an important issue. Again I am not sure how well a rapidly evolving application would be accepted (even though I am sure that, if only it were accepted, the users would ultimately get more value).

iPhone Tracking: Not Terribly Worrisome

It turns out that your iPhone keeps an unencrypted datafile containing your approximate location. You can review this datafile by using this application.

So the first question is: “What? My iPhone is ‘tracking’ me?” And the answer to that is, “yes, generally, but not to ‘Enemy of the State‘ levels.” Here, for instance, is what my iPhone knows about my location:

Some things to note:

  • That grid is pretty coarse: at least on this island,  the iPhone isn’t tracking within more than a few blocks
  • I’ve used my iPhone GPS many times in Hilo, so the coarseness of the grid is not limited by data
  • Where I work — which has notoriously bad AT&T coverage — is a curious “hole” in the grid.

These 3 things support (but do not prove) a benign explanation: the file is a cache of locations that can be used to speed the responsiveness of your iPhone’s mapping.

So far, there’s no indication that this file is in any way sent back to Apple or other parties, but it is a privacy risk, since the file is not encrypted. Apple should definitely explain the file and make it more secure in future releases. But for now, no need to panic.