Just a Theory

In my previous post, I outlined the basics of a configuration-file and dependency-tracking SQL deployment architecture, but left a couple of additional challenges unresolved. They were:

1. I would rather not have to hand-edit a configuration file, as it it’s finicky and error-prone.

2. There is still more duplication of code than I would like, in that a procedure defined in one change script would have to be copied whole to a new script for any changes, even single-line simple changes.

I believe I can solve both of these issues by simple use of a VCS. Since all of my current projects currently use Git, I will use it for the examples here.

Git it On

First, recall the structure of the configuration file, which was something like this:

[alpha]
users_table

[beta]
add_widget
widgets_table

[gamma]
add_user

[delta]
widgets_created_at
add_widget_v2

Basically, we have bracketed tags identifying changes that should be deployed. Now have a look at this:

> git log -p —format=’[%H]’ —name-only —reverse sql/deploy
[8920aaf7947a56f6777e69a21b70fd877c8fd6dc]

sql/deploy/users_table.sql
[f7da5fd4b7391747f75d85db6fa82de47b9e4c00]

sql/deploy/add_widget.sql
sql/deploy/widgets_table.sql
[ea10b9e566934ef256debe8752504189436e162a]

sql/deploy/add_user.sql
[89e85f98d891a2984ad4e3c42d8ca8cf31f3b2b4]

sql/deploy/add_widget_v2.sql
sql/deploy/widgets_created_at.sql

Look familiar? Let’s use a bit of awk magic to neaten things a bit (Thanks helwig!):

> git log -p —format=’[%H]’ —name-only —reverse sql/deploy \
| awk ‘/^\[/ {print ""} /./’

[8920aaf7947a56f6777e69a21b70fd877c8fd6dc]
sql/deploy/users_table.sql

[f7da5fd4b7391747f75d85db6fa82de47b9e4c00]
sql/deploy/add_widget.sql
sql/deploy/widgets_table.sql

[ea10b9e566934ef256debe8752504189436e162a]
sql/deploy/add_user.sql

[89e85f98d891a2984ad4e3c42d8ca8cf31f3b2b4]
sql/deploy/add_widget_v2.sql
sql/deploy/widgets_created_at.sql

Ah, that’s better. We have commit SHA1s for tags, followed by the appropriate lists of deployment scripts. But wait, we can decorate it, too:

> git log -p —format=’[%H%d]’ —name-only —reverse sql/deploy \
| awk ‘/^\[/ {print ""} /./’

[8920aaf7947a56f6777e69a21b70fd877c8fd6dc (alpha)]
sql/deploy/users_table.sql

[f7da5fd4b7391747f75d85db6fa82de47b9e4c00 (beta)]
sql/deploy/add_widget.sql
sql/deploy/widgets_table.sql

[ea10b9e566934ef256debe8752504189436e162a (gamma)]
sql/deploy/add_user.sql
[89e85f98d891a2984ad4e3c42d8ca8cf31f3b2b4 (HEAD, delta, master)]

Look at that! Actual VCS tags built right in to the output. So, assuming our deployment app can parse this output, we can deploy or revert to any commit or tag. Better yet, we don’t have to maintain a configuration file, because the VCS is already tracking all that stuff for us! Our change management app can automatically detect if we’re in a Git repository (or Mercurial or CVS or Subversion or whatever) and fetch the necessary information for us. It’s all there in the history. We can name revision identifiers (SHA1s here) to deploy or revert to, or use tags (alpha, beta, gamma, delta, HEAD, or master in this example).

And with careful repository maintenance, this approach will work for branches, as well. For example, say you have developers working in two branches, feature_foo and feature_bar. In feature_foo, a foo_table change script gets added in one commit, and an add_foo script in a second commit. Merge it into master and the history now looks like this:

> git log -p —format=’[%H%d]’ —name-only —reverse sql/deploy \
| awk ‘/^\[/ {print ""} /./’

[8920aaf7947a56f6777e69a21b70fd877c8fd6dc (alpha)]
sql/deploy/users_table.sql

[f7da5fd4b7391747f75d85db6fa82de47b9e4c00 (beta)]
sql/deploy/add_widget.sql
sql/deploy/widgets_table.sql

[ea10b9e566934ef256debe8752504189436e162a (gamma)]
sql/deploy/add_user.sql

[89e85f98d891a2984ad4e3c42d8ca8cf31f3b2b4 (delta)]
sql/deploy/add_widget_v2.sql
sql/deploy/widgets_created_at.sql

[cbb48144065dd345c5248e5f1e42c1c7391a88ed]
sql/deploy/foo_table.sql

[7f89e23c9f1e7fc298c69400f6869d701f76759e (HEAD, master, feature_foo)]
sql/deploy/add_foo.sql

So far so good.

Meanwhile, development in the feature_bar branch has added a bar_table change script in one commit and add_bar in another. Because development in this branch was going on concurrently with the feature_foo branch, if we just merged it into master, we might get a history like this:

> git log -p —format=’[%H%d]’ —name-only —reverse sql/deploy \
| awk ‘/^\[/ {print ""} /./’
[8920aaf7947a56f6777e69a21b70fd877c8fd6dc (alpha)]
sql/deploy/users_table.sql

[f7da5fd4b7391747f75d85db6fa82de47b9e4c00 (beta)]
sql/deploy/add_widget.sql
sql/deploy/widgets_table.sql

[ea10b9e566934ef256debe8752504189436e162a (gamma)]
sql/deploy/add_user.sql

[89e85f98d891a2984ad4e3c42d8ca8cf31f3b2b4 (delta)]
sql/deploy/add_widget_v2.sql
sql/deploy/widgets_created_at.sql

[cbb48144065dd345c5248e5f1e42c1c7391a88ed]
sql/deploy/foo_table.sql

[d1882d7b4cfcf5c57030bd5a15f8571bfd7e48e2]
sql/deploy/bar_table.sql

[7f89e23c9f1e7fc298c69400f6869d701f76759e]
sql/deploy/add_foo.sql

[2330da1caae9a46ea84502bd028ead399ca3ca02 (feature_bar)]
sql/deploy/add_bar.sql

[73979ede2c8589cfe24c9213a9538f305e6f508f (HEAD, master, feature_foo)]

Note that bar_table comes before add_foo. In other words, the feature_foo and feature_bar commits are interleaved. If we were to deploy to HEAD, and then need to revert feature_bar, bar_table would not be reverted. This is, shall we say, less than desirable.

There are at least two ways to avoid this issue. One is to squash the merge into a single commit using git merge —squash feature_bar. This would be similar to accepting a single patch and applying it. The resulting history would look like this:

> git log -p —format=’[%H%d]’ —name-only —reverse sql/deploy \
| awk ‘/^\[/ {print ""} /./’

[8920aaf7947a56f6777e69a21b70fd877c8fd6dc (alpha)]
sql/deploy/users_table.sql

[f7da5fd4b7391747f75d85db6fa82de47b9e4c00 (beta)]
sql/deploy/add_widget.sql
sql/deploy/widgets_table.sql

[ea10b9e566934ef256debe8752504189436e162a (gamma)]
sql/deploy/add_user.sql

[89e85f98d891a2984ad4e3c42d8ca8cf31f3b2b4 (delta)]
sql/deploy/add_widget_v2.sql
sql/deploy/widgets_created_at.sql

[cbb48144065dd345c5248e5f1e42c1c7391a88ed]
sql/deploy/foo_table.sql

[7f89e23c9f1e7fc298c69400f6869d701f76759e]
sql/deploy/add_foo.sql

[91a048c05e0444682e2e4763e8a7999a869b4a77 (HEAD, master)]
sql/deploy/add_bar.sql
sql/deploy/bar_table.sql

Now both of the feature_bar change scripts come after the feature_foo changes. But it might be nice to keep the history. So a better solution (and the best practice, I believe), is to rebase the feature_bar branch before merging it into master, like so:

> git rebase master
First, rewinding head to replay your work on top of it...
Applying: Add bar.
Applying: Add add_bar().
> git checkout master
Switched to branch ‘master’
> git merge feature_bar
Updating 7f89e23..0fab7a0
Fast-forward
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 sql/deploy/add_bar.sql
 create mode 100644 sql/deploy/bar_table.sql
 create mode 100644 sql/revert/add_bar.sql
 create mode 100644 sql/revert/bar_table.sql

And now we should have:

> git log -p —format=’[%H%d]’ —name-only —reverse sql/deploy \
| awk ‘/^\[/ {print ""} /./’

[8920aaf7947a56f6777e69a21b70fd877c8fd6dc (alpha)]
sql/deploy/users_table.sql

[f7da5fd4b7391747f75d85db6fa82de47b9e4c00 (beta)]
sql/deploy/add_widget.sql
sql/deploy/widgets_table.sql

[ea10b9e566934ef256debe8752504189436e162a (gamma)]
sql/deploy/add_user.sql

[89e85f98d891a2984ad4e3c42d8ca8cf31f3b2b4 (delta)]
sql/deploy/add_widget_v2.sql
sql/deploy/widgets_created_at.sql

[cbb48144065dd345c5248e5f1e42c1c7391a88ed]
sql/deploy/foo_table.sql

[7f89e23c9f1e7fc298c69400f6869d701f76759e]
sql/deploy/add_foo.sql

[0e53c29eb47c618d0a8818cc17bd5a0aab0acd6d]
sql/deploy/bar_table.sql

[0fab7a0ba928b34a46a9495d4efc1c73d9133d37 (HEAD, master, feature_bar)]
sql/deploy/add_bar.sql

Awesome, now everything is in the correct order. We did lose the feature_foo “tag,” though. That’s because it wasn’t a tag, and neither is feature_bar here. They are, rather, branch names, which we becomes obvious when using “full” decoration:

git log —format=’%d’ —decorate=full HEAD^..      
 (HEAD, refs/heads/master, refs/heads/feature_foo)

After the next commit, it will disappear from the history. So let’s just tag the relevant commits ourselves:

> git tag feature_foo 7f89e23c9f1e7fc298c69400f6869d701f76759e
> git tag feature_bar
> git log -p —format=’[%H%d]’ —name-only —reverse sql/deploy \
| awk ‘/^\[/ {print ""} /./’

[8920aaf7947a56f6777e69a21b70fd877c8fd6dc (alpha)]
sql/deploy/users_table.sql

[f7da5fd4b7391747f75d85db6fa82de47b9e4c00 (beta)]
sql/deploy/add_widget.sql
sql/deploy/widgets_table.sql

[ea10b9e566934ef256debe8752504189436e162a (gamma)]
sql/deploy/add_user.sql

[89e85f98d891a2984ad4e3c42d8ca8cf31f3b2b4 (delta)]
sql/deploy/add_widget_v2.sql
sql/deploy/widgets_created_at.sql

[cbb48144065dd345c5248e5f1e42c1c7391a88ed]
sql/deploy/foo_table.sql

[7f89e23c9f1e7fc298c69400f6869d701f76759e (feature_foo)]
sql/deploy/add_foo.sql

[0e53c29eb47c618d0a8818cc17bd5a0aab0acd6d]
sql/deploy/bar_table.sql

[0fab7a0ba928b34a46a9495d4efc1c73d9133d37 (HEAD, feature_bar, master, feature_bar)]
sql/deploy/add_bar.sql

Ah, there we go! After the next commit, one of those feature_bars will disappear, since the branch will have been left behind. But we’ll still have the tag.

Not Dead Yet

Clearly we can intelligently use Git to manage SQL change management. (Kind of stands to reason, doesn’t it?) Nevertheless, I believe that a configuration file still might have its uses. Not only because not every project is in a VCS (it ought to be!), but because oftentimes a project is not deployed to production as a git clone. It might be distributed as a source tarball or an RPM. In such a case, including a configuration file in the distribution would be very useful. But there is still no need to manage it by hand; our deployment app can generate it from the VCS history before packaging for release.

More to Come

I’d planned to cover the elimination of duplication, but I think this is enough for one post. Watch for that idea in my next post.

I’ve been thinking a lot about SQL change management. I know I have written about this before. But I was never satisfied with that idea, mostly because it required managing database changes in two separate but interdependent ways. Blargh. So for my Perl projects the last couple of years, I have stuck to the very simple but ugly Rails-style migration model, as implemented in Module::Build::DB.

But it has been on my brain more lately because I’m writing more and more database applications at work, and managing changes over time is becoming increasingly annoying. I’ve been using a variation on Depesz’s Versioning package, mainly because its idea of specifying dependencies instead of ordered deployment scripts is so useful. However, its implementation in pure SQL, with accompanying shell and Perl scripts, is not entirely satisfying. Worse, one cannot easily include the contents of an earlier deployment script in a reversion script, because the dependency registration function embedded in a script will throw an error if it has been run before. The upshot is that if you make a one-line change to a database function, you still have to paste the entire thing into a new file and commit it to your source code repository. This makes tracking diffs annoying.

Oh, and did I mention that there is no simple built-in way to revert changes, and even if there were, because there are no named releases, it can be difficult to decide what to revert to? I don’t often need that capability, but when I need it, I need it.

Then, this week, Robert Haas described a deployment implementation he implemented. It was simple:

My last implementation worked by keeping a schema_versions table on the server with one column, a UUID. The deployment tarball contained a file with a list of UUIDs in it, each one associated to an SQL script. At install time, the install script ran through that file in order and ran any scripts whose UUID didn’t yet appear in the table, and then added the UUIDs of the run scripts to the table.

I like this simplicity, but there are some more things I think could be done, including dependency reslolution and reversion. And it seems silly to have a UUID stand for a script name; why not just list script names? Better yet, tag groups of changes for easy reference.

Yet Another SQL Deployment Strategy

So here’s my proposal. Following Robert, we create a configuration file, but instead of just listing changes, we fill it with tags and the names of the changes are associated with each. An example:

[alpha]
users_table

[beta]
add_widget
widgets_table

[gamma]
add_user

Our change management app will parse this file, finding the tag for each stage of the migration in brackets, and apply the associated changes, simply finding each of them in sql/deploy/$change.sql. If it’s reverting changes, it finds the reversion scripts named sql/revert/$change.sql. The tags can be anything you want; release tags might be useful. Easy so far, right?

Except notice that I have a minor ordering problem here. The add_widget change, which adds a function to insert a record into the widgets table, comes before the widgets_table script. If we run the add_widget change first, it will fail, because the widgets table does not yet exist.

Of course we can re-order the lines in the configuration file. But given that one might have many changes for a particular tag, with many cross-referenceing dependencies, I think it’s better to overcome this problem in the scripts themselves. So I suggest that the sql/deploy/add_widget.sql file look something like this:

— requires: widgets_table

CREATE OR REPLACE FUNCTION add_widget(
    username   TEXT,
    widgetname TEXT
) RETURNS VOID LANGUAGE SQL AS $$
    INSERT INTO widgets (created_by, name) VALUES ($1, $2);
$$;

Here I’m stealing Depesz’s dependency tracking idea. With a simple comment at the top of the script, we specify that this change requires that the widgets_table change be run first. So let’s look at sql/deploy/widgets_table.sql:

— requires: users_table

CREATE TABLE widgets (
    created_by TEXT NOT NULL REFERENCES users(name),
    name       TEXT NOT NULL
);

Ah, now here we also require that the users_table change be deployed first. Of course, it likely would be, given that it appears under a tag earlier in the file, but it’s best to be safe and explicitly spell out dependencies. Someone might merge the two tags at some point before release, right?

The users_table change has no dependencies, but the later add_user change of course does; our sql/deploy/add_user.sql:

— requires: users_table

CREATE OR REPLACE FUNCTION add_user(
    name TEXT
) RETURNS VOID LANGUAGE SQL AS $$
    INSERT INTO users (name) VALUES ($1);
$$;

Our deployment app can properly resolve these dependencies. Of course, we also need reversion scripts in the sql/revert directory. They might look something like:

— sql/revert/users_table.sql
DROP TABLE IF EXISTS users;

— sql/revert/add_widget.sql
DROP FUNCTION IF EXISTS add_widget(text, text);

— sql/revert/widgets_table.sql
DROP TABLE IF EXISTS widgets;

— sql/revert/add_user.sql
DROP FUNCTION IF EXISTS add_user(text);

So far so good, right? Our app can resolve dependencies in both directions, so that if we tell it to revert to beta, it can do so in the proper order.

Now, as the deployment app runs the scripts, deploying or reverting changes, it tracks them and their dependencies in its own metadata table in the database, not unlike Depesz’s Versioning package. But because dependencies are parsed from comments in the scripts, we are free to include the contents of one script in another. For example, say that we later need to revise the add_widget() function to log the time a widget is created. First we add a new script to add the necessary column:

— requires: widgets_table
ALTER TABLE widgets ADD created_at TIMESTAMPTZ;

Call that script sql/deploy/widgets_created_at.sql. Next we add a script that changes add_widgets():

— requires widgets_created_at
CREATE OR REPLACE FUNCTION add_widget(
    username   TEXT,
    widgetname TEXT
) RETURNS VOID LANGUAGE SQL AS $$
    INSERT INTO widgets (created_by, name, created_at)
    VALUES ($1, $2, NOW());
$$;

Call it sql/deploy/add_widget_v2.sql. Then update the deployment configuration file with a new tag and the associated changes:

[delta]
widgets_created_at
add_widget_v2

With me so far? Now, what about reversion? sql/revert/widgets_created_at.sql is simple, of course:

ALTER TABLE widgets DROP COLUMN IF EXISTS created_at;

But what should sql/revert/add_widget_v2.sql look like? Why, to go back to the first version of add_widget(), it would be identical to sql/deploy/add_widget.sql. But it would be silly to copy the whole file, wouldn’t it? Why duplicate when we can just include?

\i sql/deploy/add_widget.sql

Boom, we get the reversion script for free. No unnecessary duplication between deployment and reversion scripts, and all dependencies are nicely resolved. Plus, the tags in the configuration file make it easy to deploy and revert change sets as necessary, with dependencies properly followed.

There’s More!

To recap, I had two primary challenges with Depesz’s Versioning package to overcome: inability to easily revert to an earlier implementation; and the inability to easily include one script in another. Both of course are do-able with workarounds, but I think that the addition of a deployment configuration file with tagged sets of changes and the elimination of SQL-embedded dependency specification overcome these issues much more effectively and intuitively.

Still, there are two more challenges I would like to overcome:

1. It would be nice not to need the configuration file at all. Maintaining such a thing can be finicky and error-prone.

2. I still had to duplicate the entire add_widget() function in the add_widget_v2 script for a very simple change. This means no easy way to simply see the diff for this change in my VCS. It would be nice not to have to copy the entire function.

I think I have solutions for these issues, as well. More in my next post.

Hey look everybody, I wrote today’s Perl Advent Calendar post, Less Tedium, More Transactions. Go read it!

I’ve started using TestFlight to release DesignScene betas to testers. The documentation is thin, so I had to futz a bit, but fortunately it’s a pretty simple app, so once I figured out that I just needed to stick to one "Team", I was off and running. And let me tell you, TestFlight is a far easier way to distribute betas than the convoluted methods suggested by Apple. Much more beta user-friendly.

For us developers, the TestFlight SDK is particularly handy. Add it to your TestFlight-distributed project and get crash reports and remote logging, ask your testers for feedback, and other cool stuff. I’ve only just started using it, but the immediate diagnostic feedback has already proved invaluable.

Getting the TestFlight SDK to work is dead simple, but it’s not supported in App Store distributions. So I wanted to set things up so that it would always be included in beta releases and never in production releases. Getting to that point took a couple of days of futzing, as it’s not explicitly supposed by Xcode’s UI. The solution I came up with, thanks to this StackOverflow post, is to:

• Add a "Beta" configuration to complement the default "Release" and "Debug" configurations
• Add a preprocessor macro to allow conditional use of the TestFlight SDK
• Use the EXCLUDED_SOURCE_FILE_NAMES setting to exclude the TestFlight library from "Release" builds

That last step makes me a bit nervous, but EXCLUDED_SOURCE_FILE_NAMES, while undocumented, seems to be reasonably well known. At any rate, I could find no better way to tie the inclusion of a library to a specific configuration, so I’m going with it. Better solutions welcome.

At any rate, here’s the step-by-step for Xcode 4.2:

• Download the TestFlight SDK and unpack it.
• Drag it into your project. Make sure that "Copy items into destination group’s folder" is checked, as is "Create groups for any added folders". Include it in all relevant targets.

• Create a "Beta" configuration:

  • Click on the app name in the navigator, then on the project name and then the info tab.
  • Under "Configurations", click the plus sign and select "Duplicate "Release" Configuration"
  • Type "Beta" to name the new configuration.

  You should end up with something like this:

  

• Create configuration marcos:

  

  • Still in the project settings, go to the "Build Settings" tab.
  • Search for "preprocessor macros".
  • Double-click the value section next to the "Preprocessor Macros" label, hit the + button, and enter CONFIGURATION_$(CONFIGURATION).

  You should end up with a window like the above. Once you close it, you should see the macros names for each individual configuration, shown here:

  

• Add the EXCLUDED_SOURCE_FILE_NAMES build setting.

  • Still in the "Build Settings" tab, click the "Add Build Setting" button in the lower-left corner and select "Add User-Defined Setting".
  • Input EXCLUDED_SOURCE_FILE_NAMES as the name of the setting.
  • Open the reveal triangle next to the setting name.
  • Double-click to the right of "Release".
  • Enter *libTestFlight.a as the value.

  You should end up with the value *libTestFlight.a only for the "Release" configuration, as shown here:

  

• Go ahead and use the TestFlight SDK:

  • In your app delegate, add #include "testFlight.h"

  • In -application:didFinishLaunchingWithOptions:, just before returning, add these lines:

    #ifdef CONFIGURATION_Beta
        [TestFlight takeOff:@"Insert your Team Token here"];
    #endif

Now, when you build or archive with the "Beta" target, the TestFlight SDK will be included and log sessions. But when you build with the "Release" target, TestFlight will neither be bundled or referenced in the app. You can include it anywhere, though, and use any of its features, as long as you do so only within a #ifdef CONFIGURATION_Beta block. Check out the complete SDK docs for details. Then, get your beta on!

Since June, as part of my work for PGX, I’ve been doing on-site full-time consulting for iovation here in Portland. iovation is in the business of deterring online fraud via device identification and reputation. Given the nature of that business, a whole lot of data arrives every day, and I’ve been developing PostgreSQL-based solutions to help get a handle on it. The work has been truly engaging, and a whole hell of a lot of fun. And there are some really great, very smart people at iovation, whom I very much like and respect.

So much so, in fact, that I decided to accept their offer of a full time position as “Senior Data Architect.” I started on Monday.

I know, crazy, right? They’ve actually been talking me up about it for a long time. In our initial contact close to two years ago, as I sought to land them as a PGX client, they told me they wanted to hire someone, and was I interested. I said “no.” I said “no” through four months of contracting this summer and fall, until one day last month I said to myself, “wait, why don’t I want this job?” I had been on automatic, habitually insisting I wasn’t interested in a W2 position. And with good reason. Aside from 15 months as CTO at values of n (during which time I worked relatively independently anyway), I’ve been an independent consultant since I founded Kineticode in November of 2001. Yeah. Ten Years.

Don’t get me wrong, those ten years have been great! Not only have I been able to support myself doing the things I love—and learned a ton in the process—but I’ve managed to write a lot of great code. Hell, I will be continuing as an associate with PGX, though with greatly reduced responsibilities. And someday I may go indy again. But in the meantime, the challenges, opportunities, and culture at iovation are just too good to pass up. I’m loving the work I’m doing there, and expect to learn a lot over the next few years.

So what, you might ask, does this mean for Kineticode, the company I founded to offer support, consulting, and training services for Bricolage CMS? The truth is that Kineticode has only a few technical support customers left; virtually all of my work for the last two years has been through PGX. So I’ve decided to shut Kineticode down. I’m shifting the Bricolage tech support offerings over to PGX and having Kineticode’s customers move there as their contacts come up for renewal. They can expect the same great service as always. Better even, as there are 10 associates in PGX, and, lately, only me at Kineticode. Since Kineticode itself is losing its Raison d’être, it’s going away.

I intend to remain involved in the various open-source projects I work on. I still function as the benevolent dictator of Bricolage CMS, though other folks have stepped up their involvement quite a lot in the last few years. And I expect to keep improving PGXN and DesignScene as time allows (I’ve actually been putting some effort into both in the last few weeks; watch for PGXN and Lunar/Theory announcements in the coming weeks and months!). And, in fact, I expect that a fair amount of the work I do at iovation will lead to blog posts, conference presentations, and more open-source code.

This is going to be a blast. Interested in a front-row seat? Follow me on Twitter.

After posting my thoughts on the Isaacson Steve Jobs biography a couple weeks ago, I finally let myself check out some of the deeper pieces on the topic by folks I respect. John Siracusa’s take was particularly enlightening, as his familiarity with the existing sources empowers a deeply authoritative critique of the biography. But it’s John Gruber’s “Getting Steve Jobs Wrong” that validates my general feeling of dissatisfaction with Isaacson’s biography. This bit nails it:

Jobs understood technology but was not an engineer. He had profoundly exquisite taste but was not a designer. What it was that Jobs actually did is much of the mystery of his life and his work, and Isaacson, frustratingly, had seemingly little interest in that, or any recognition that there even was any sort of mystery as to just what Jobs’s gifts really were.

Yes, exactly! Isaacson does not seem interested in what made Jobs tick; that’s a real shame for those of us who are. I was ready to cut Isaacson a bit of slack, as writing a biography is very difficult, and writing a definitive one damn near impossible. But since Gruber hits the same point I tried make, and Siracusa has pretty thoroughly decimated Isaacson’s authority, I’m now far less willing to do so. Isaacson just seems incurious about his subject, whereas the best biographers are obsessed. A lack of curiosity ought to disqualify one for the job.

As Siracusa says, Steve Jobs picked the wrong guy.

Until a few weeks ago, the biography I read most recently was Dutch, Edmund Morris’s authorized portrait of Ronald Reagan. I read it not because I was interested in Reagan, but because Morris did something unique: he inserted himself into Reagan’s story as a (mostly) fictional character. Why would he do that? Morris grew up in Kenya, far from Reagan’s childhood in Illinois, not to mention years later. And yet there he was, a peripheral character throughout the story of Reagan’s life. What was the point?

Reading the book, the most striking thing about Reagan was how impenetrable he was. No one ever got through to him, to really know him. Perhaps it’s because there was no there there, or maybe there was an interesting person under the bland exterior he used to keep everyone out. It was impossible to know.

Such a personality must frustrate biographers. I want a deep understanding of the subject of a biography, to know what makes her tick, what her motivations and drives are. I want to get inside her head. But Morris couldn’t do that with Reagan. No one could.

I hypothesize that Morris stuck himself in the story, calling it a “Memoir of Ronald Reagan,” to contrast his subject with someone who’s head he could get into. And through that contrast, he drew out a little bit of something to demonstrate what made Reagan tick. Not a lot mind you, but it was an interesting attempt.

I thought about this as I read Steve Jobs, an authorized biography by Walter Isaacson. I’ve been a fan of Apple’s products and vision for many years, but never delved deeply into the wealth of literature on Jobs himself or personal stories such as the birth of the Mac. My main exposure to Steve has been through his keynote presentations and various interviews and appearances over the years. I watch Apple relatively closely, but not Steve. In reading the biography, I wanted to get to know him, to get a feel for the man, and, above all, to find out what makes him tick.

Steve Jobs did give me a feel for the man. Many of the stories about his personality appear to be true. Steve Jobs was clearly a tyrant, but a tyrant with taste. I was struck by the constant theme that Jobs somehow believed that the usual rules don’t apply to him. At one point, pulled over for driving over 100 MPH, Jobs impatiently waits for the ticket, even demanding that the Chippy hurry up. Ticket at last in hand, he drives right up over 100 MPH again, despite a warning that he could lose his license.

Jobs’s famed reality distortion field let him pretend that rules didn’t apply to him, that the world was exactly what he imagined it to be. This ability had advantages (cajolling the CEO of Corning to complete the “impossible” task to start producing huge volumes of Gorilla Glass virtually over night) and disadvantages (trying to cure his cancer with extreme diets).

It was that supreme confidence, combined with his taste, that shaped Jobs’s career and the success of Apple. When it comes to taste, Steve was continually, obsessively product-focused. The quality of the products had to be top notch. You get a feeling for this not so much in the successes of the Macintosh, iPod, iPhone, and iPad, which are well-known, but on the things that shouldn’t matter. Deathly ill following his liver transplant, Jobs was still Jobs:

At one point the pulmonologist tried to put a mask over his face when he was deeply sedated. Jobs ripped it off and mumbled that he hated the design and refused to wear it. Though barely able to speak, he ordered them to bring five different options for the mask and he would pick a design he liked. The doctors looked at Powell, puzzled. She was finally able to distract him so they could put on the mask. He also hated the oxygen monitor they put on his finger. He told them it was ugly and too complex. He suggested ways it could be designed more simply. “He was very attuned to every nuance of the environment and objects around him, and that drained him,” Powell recalled.

This is perhaps the most striking of many examples of Jobs’s obsession with quality and taste, and deftly captures the essence of it. I imagine Jobs thought about how to improve things in his life every second of his life. In his dreams, he might be improving the design of his pajamas or bedroom dresser.

The product obsession drives the book’s narrative, right down to its organization. A few chapters necessarily cover personal events, such as early years, love and marriage, and illness. More are organized around products. Relevant chapter titles:

• 4: Atari and India: Zen and the Art of Game Design
• 5: The Apple I: Turn On, Boot Up, Jack In…
• 6: The Apple II: Dawn of a New Age
• 8: Xerox and Lisa: Graphical User Interfaces
• 10: The Mac is Born: You Say You Want a Revolution
• 12: Design: Real Artists Simplify
• 13: Building the Mac: The Journey is the Reward
• 15: The Launch: A Dent in the Universe
• 18: NeXT: Prometheus Unbound
• 19: Pixar: Technology Meets Art
• 22: Toy Story: Buzz and Woody to the Rescue
• 27: The iMac: Hello (Again)
• 29: Apple Stores; Genius Bars and Sienna Sandstone
• 30: The Digital Hub: From iTunes to the iPod
• 31: The iTunes Store: I’m the Pied Piper
• 34: Twenty-first-century Macs: Setting Apple Apart
• 36: The iPhone: Three Revolutionary Products in One
• 38: The iPad: Into the Post-PC Era
• 40: To Infinity: The Cloud, the Spaceship, and Beyond

That’s nearly half of them, and all but a few of the others also include extensive discussion of products and design. Clearly Jobs was a man obsessed, that obsession shaped every facet of his life, and it therefore shaped the narrative of his biography.

But where does this come from? From whence derives the absolute faith in even the most most questionable ideas, the unwavering belief in his own infallibility, the near complete obsession with the design of everyday things? I see the ticks, but what makes him tick?

The truth is we don’t know. Isaacson doesn’t know. Sure, there are a few hypotheses about his adoption, about his parents insisting he was special. But I don’t know. Explaining Steve Jobs by his adoption seems like a cop-out. There are millions of adopted people, many with no doubt similar histories (educated biological parents, doting middle-class adoptive parents). But there’s only one Steve Jobs. Jobs himself didn’t buy it, saying he hardly thought about his adoption.

There is also discussion of his study of Zen Buddhism, and his love for simple, beautiful places like Kyoto and Kona Village. I’ve studied a bit of Zen Buddhism and visited Kyoto and Kona Village too, and have a deep appreciation for the beauty of all three. But I’m no Steve Jobs. Perhaps Steve dove very deeply into Zen Buddhism, so that through years of study and practice he became who he was (though, let’s face it, his personality couldn’t be much less Zen). But if so, I think it gets short shrift in Isaacson’s telling.

Perhaps it’s unfair to demand so much of a biographer. I want to go into the head of his subject, on a quest for a deeper understanding of the essence of the person, and come away with a greater knowledge his humanity. Such was impossible for Morris to do with Reagan, and it’s not fair to expect more of Isaacson with Steve Jobs. Not only was Jobs a deeply complex man with an impenetrable presence (one wonders how well Laurene Powell really got to know him; I’d like to read her book), but, hey, how much can one understand anyone else? People have been trying for centuries to understand Thomas Jefferson and Ben Franklin (including Isaacson!), with, let’s face it, limited success. It’s rare that a biography becomes so completely deep and authoritative — so true, the definitive telling — that no more biographies follow. More often new folks come along, taking different tacks to understand the ticks. Perhaps the best sense we get of an elephant is through the descriptions of all the blind people feeling different parts of the elephant.

I think my favorite tidbit from the book is Jobs playing a rare bootleg CD with a dozen taped sessions of the Beatles “Strawberry Fields Forever,” a gift from Andy Hertzfeld. Listening to the CD with Isaacson, Jobs talks about how the Beatles kept iterating, kept improving the song, working on every aspect over a period of time, getting it “closer to perfect.” Then he says:

The way we build stuff at Apple is often this way. Even the number of models we’d make of a new notebook or iPod. We would start off with a version and then begin refining and refining, doing detailed models of the design, or the buttons, or how a function operates. It’s a lot of work, but in the end it just gets better, and soon its like, “Wow, how did they do that?!? Where are the screws?”

So maybe it’s fair that the narrative is largely product-driven. Jobs talked often over the years about how important good products are to him, much more important than profit, and the book reinforces that. He lived and breathed taste and products, to the exclusion of all else, including, at times, his family and his health.

Perhaps, then, what made Jobs tick was the iPhone and the iPad, and the exultation of being a part of creating a truly inspiring product.