So after the suggestions given in the comments section the build script I’m using now uses PlistBuddy (which I wanted to use before but didn’t know the correct path), and increments only if we’re building the release build. (It was an interesting exercise to see my project’s build number go up into the thousands–but a build number that looks like a zip code isn’t really useful.)

Here is the current script which I’m using.

# Auto increment version number from build common file

use strict;

die "$0: Must be run from Xcode" unless $ENV{"BUILT_PRODUCTS_DIR"};

# Get the current revision number and use it to set the CFBundleVersion value
open FH, "build.count" or die;
my $version = join("",);
close(FH);

if ($ENV{CONFIGURATION} eq "Release") {
	++$version;

	open FH, ">build.count" or die;
	print FH $version;
	close(FH);
}

$version = "1.1 ($version)";
print "Build $versionn"; 

# Update info.plist in build product. Use defaults command
	
my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Info.plist";
my @cmd = ( '/usr/libexec/PlistBuddy', '-c', "Set :CFBundleVersion $version", $INFO );
exec @cmd;

Note that this is Perl, which means you need to set the Shell to “/usr/bin/perl -w” when you set this as the run script phase.

This works on my iPhone software. For Macintosh builds you need to change the third-to-last line to:

my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Contents/Info.plist";

And don’t forget to create a build.count file in the same directory as your project file and set the text file to the starting build count.

So here’s the problem if you’re a maker and someone is looking at you to be a manager.

On the one hand, a manager can accomplish far more than a maker, in the aggregate: look at Steve Jobs. One could almost look at Apple as an expression of Steve Job’s will; he has assembled some of the brightest minds to accomplish some really fantastic things–all in accord to his sensibilities.

On the other hand, being a manager is, for a died in the wool maker, a really shallow and annoying job.

And there is an additional penalty as one makes the transition from maker to manager. The difference between a really experienced software developer and a mediocre developer is, according to The Mythical Man Month, something like a factor of 25 in productivity. Further, when you start managing people, you find yourself spending time in meetings–meaning you can kiss about half of your day goodbye unless you adhere to a very strict scheduling regime. And even then, at best you can save four days out of five.

So this means that your first employee–being inexperienced at the product being worked on–will cause you to lose at least a factor of 5 in productivity in order to gain 1.

There is, in other words, a depression–a chasm–which forms between your best productive days as a maker, and as a manager leading a large team. The least optimal environment to be in is as a maker at the top of your game managing 2 or 3 makers who are just getting started.

In the end, if you continue and persevere, you can be even more productive–eventually–than you ever were as a maker. Maybe.

It becomes worse when the transition takes place when there is a need: in essence you’re doubling or tripling the salary burn rate while reducing overall productivity at a time when you can ill afford the lost in productivity.

And of course don’t forget you’re moving into that dreaded position: middle management, a position which, during the current recession, has proven to be expendable.

I will admit I will never understand the current craze of social networking. I don’t understand Twitter. I don’t get Facebook. (Actually I think Facebook is the spawn of Satan, but that’s a different post.) I don’t get MySpace. The idea of a software program on my cell phone broadcasting my current location to my friends is something I simply don’t grok: the idea that I should sacrifice that degree of privacy for some degree of notoriety seems strange to me.

In my day, the idea that the Government would be able to plant microchips in our minds in order to track our movements was a sure sign of madness–today we volunteer to carry around electronic devices we pay for (and pay the networking usage of) so we can install software that allows Corporations to track our every movement. (And if you suggested we would do this twenty years ago, my friends and I would have thought you were completely out of your mind certifiably insane.)

But I have to remember something: the 20-somethings I currently work with were 10, 11 and 12 when the World Wide Web was invented. For me, I still remember bang paths. It was how we routed mail before the invention of DNS. And I was in college at that time. I still remember when there was an informal injunction against ads on Usenet Network News because many of us were getting our Arpanet connections via a DoD contract, which prohibited advertising.

So the idea that we would use all of this to communicate with other people socially–or the idea that we would volunteer as much personal, private information to corporations who then promise to resell that information for advertising purposes–still strikes me as extremely strange.

On our corporate blog I posted a somewhat irritated little screed, which was originally triggered by an e-mail message sent to me by a service provider who said that a pirated copy of our software, which was leaked by a member of the press, was using a test account for obtaining its location–and the test account was daily hitting its limit. That caused our pirated version of the software to stop updating its location–and the failure of the pirated copy to update its location was resulting in negative public reviews.

And PR rewrote the article.

Now I’m not irritated at the rewrite. The reality is that for a public facing corporate blog, the blog is owned by the corporation. If someone at PR decides they want to review all posts before they go out or if they decide to edit or rewrite all blog posts, that’s their prerogative: I’m not one of those fools who believes the First Amendment also applies to private citizens and corporations.

But I am irritated, from an intellectual standpoint, that my name is still associated with the post. I know, it’s counter-intuitive: most people would be glad to get credit on what is, in the end, a much better article than the one I originally posted. (It’s less obnoxious, for example.) But it’s the the guy who attended Caltech asserting himself: intellectual honesty demands that if someone rewrites my article, that person deserves the credit, not I.

Update: The request was acknowledged, and the post is now no longer in my name.

It could be that I will never be a successful CEO of my own corporation of a thousand person corporation: I don’t like giving credit where it is not deserved and I don’t like taking credit where it is not due. And from what I’ve seen over the past few years, corporation building seems to involve a lot of people taking credit where it is not due, and giving credit where it is not deserved. (I’m partially irritated because at one point in one conversation I had someone come up to me while I was standing in front of an investor ask me if we had a “great client development team,” and I replied “yes, we do.” Um, what team? Me, myself and I? But I had to play the game. Feh.)

The sad thing is I’m not even irritated that this is the world works. I may as well also be irritated by the fact that gravity makes me heavy, hot things burn, and occasionally into everyone’s life a little rain must fall.

The reason is simple, by the way: investors, customers, and the general public like to believe in a company, a product, an image. Our preconceived notions often make it difficult for us to believe that one person is responsible for a thing, or they want a single individual to root for. To violate this image–to suggest, for example, that Steve Jobs is not the center of the Apple Universe, or that some anonymous programmer drove the complete rewrite of iMovie’s new user interface–is to run against this public perception. And it causes people to lose confidence in what it is you’re trying to sell, when you show them what’s behind the curtain and it’s not what they think it should be.

The play’s the thing–even if the “play” is serving a customer at a restaurant, or providing them QA feedback, or downloading a cool free app from the Android Marketplace or the Apple iTunes App Store.

On a related note, it’s why I believe when there is a public facing corporate blog, individual bloggers should also have their own blog, separate from the PR feed. That way, individual posts from individual bloggers can be separated out from the main PR message.

We all have our own voices. It’s intellectually dishonest to run all of our voices through the PR speak filter–though I’m fine with PR asking for a post to be taken down because it violates a contractual requirement or doesn’t represent the public voice the company wants to project. I would never write the following sentence in a million years: “Although this was not an official release, we were thrilled to hear the overwhelmingly positive response to the application, and to see people really talking it up around the various social networks.” That’s because I don’t follow social networks. I’m a coder, I have better things to do than waste my time on Facebook. Marketing follows uptake; that’s their job. Mine is to produce great code within the platform, time, corporate and political constraints presented me.

Like all developers, I hate giving estimates as to how long it will take to write some code or fix it. The real problem is that you can’t really honestly know how long it will take something until you’ve solved all the known-unknown and (worse) unknown-unknown problems. And by that time, well–you’re done.

There are, however, rules of thumb we can apply to estimate how long it will take to write some code: a feel for the size of the problem, a vague sketch of the architecture in your head, the mental checklist on the APIs you’ll need to access–and experience allows you to give a rough estimate on how long it will take to write new code.

For me, estimating new code is relatively easy: I have a rough feel for it. But estimating fixing bugs–that’s a whole different animal, because it consists of two sorta-known unknowns:

(1) How do I reproduce the problem? You can’t fix it until you can reproduce it, and sometimes it’s hard to figure out how to reproduce a problem.

(That’s why a good QA or QAE is so damned hard to find, but so invaluable to the development process: a good QA or QAE can give you specific steps to reliably reproduce a problem. It’s also why a well-written bug report must include specific steps which reliably reproduce a problem.)

(2) Is the problem a simple fix? Or am I going to have to rewrite something? Sometimes a bug is as simple as “oops, forgot to set up a variable before calling a routine”–and with good reproduction steps it could take just a few minutes to test, debug, validate, and push out to QA for verification.

Sometimes the problem requires a massive rewrite.

And you can’t know until you know what the problem is.

For me, I estimate these defects based on if the steps to reproduce are simple or if the problem is a vague “it crashes when I wave it through the air,” and if the area in the code sounds (and the nature of the bug) sounds like it’s a “hmmm, I wonder if I skipped an important step” or a “oh, God; do I need to rewrite that module?” And while you can get a feel for it, it’s not an exact science since you’re estimating the time to resolve two sorta-known unknowns (that is, I know they’re unknown, but I don’t know how unknown my unknowns are)–well…

To give a concrete example I got a bug report that said “sometimes it crashes when I start up the application.” Someone asked me for an estimate. I told them “I think it’s a simple crash, but I don’t know how to reproduce it. Maybe two days?”

Then QA privately e-mailed me with specific steps.

And two days became 15 minutes.

Anatomy Of A Feature