Rewriting is almost never a good idea, as Joel Spolsky explained in a memorable essay. And premature optimization is “the root of all evil” about 97% of the time, according to Donald Knuth. Bug fixes removed in the name of clarity will have to be re-discovered and re-added; wrong-headed optimizations will have to be removed.

And who decides which code issues should be classified as “technical debt”? It seems very subjective.

Programming isn’t a code-production activity, it’s a knowledge-acquisition activity. Good programmers don’t focus on cranking out code and then fixing it later. They continually rewrite code as necessary to solve problems / add features / improve performance as their understanding of the problem increases.

If you’re managing programmers and they say something about accumulating technical debt, ask them about it. Ask why they consider it technical debt. Have a discussion about what it really means and whether it’s a valid concept or an excuse.

Some Mac developers think this is a signal that the Mac is not so important to Apple anymore. Mac sales for the second quarter of fiscal 2010 were up 32% year-over-year, but is that growth sustainable over the longer term?

Charlie Stross’s insightful post suggests the personal computer industry will become much more of a commoditized “profitability wasteland” because underlying prices keep dropping, and that coming wireless networking speeds will increase to the point where users can move their data to the cloud because they’ll finally have fast-enough access to it from anywhere. Apple is building a $1 billion data center in North Carolina, perhaps to be ready for this shift.

So what does the future look like then? For Apple it seems to be centered around the iPad and iPhone.

If you’re a typical consumer, in a few years you won’t buy a “computer” anymore, and you’ll probably be glad to be free of its headaches. Instead, you’ll buy an iPad and an Apple Service “subscription”. Everything else will be taken care of, at least from Apple’s point of view. All your information will be stored and (hopefully) protected by the Apple Service. Your information will be usable from several devices, as long as they’re all Apple devices. And you’ll keep buying “apps”, which scale much better as a business for Apple — Apple collects 30% of the sale at near-zero per-unit cost compared to hardware.

Consumers will take to this approach, at least for a while. In a comment on the post The iPad isn’t a computer, it’s a distribution channel, Mike Jones writes, “as long as people demand more performance than can be delivered, an integrated and closed platform is the best way to deliver. As soon as the market becomes over served, people will start demanding flexibility and customization, and then the platform (or a competitors) will open up just like a PC.” I hope so.

This shift raises lots of questions for me, such as:

What about people who value privacy and control over their data?

What does it mean for an independent Mac software vendor over the next 5-10 years?

So, I wrote a simple utility called appversion which prints the value for the CFBundleVersion key in an app’s Info.plist.

For example:

	appversion /Applications/iPhoto.app

yields:

	8.1

Download the 32/64-bit Universal binary (in a zip file) here:

appversion.zip

So, Arq needs its own “crash reporter”. After reading Daniel Jalkut’s nice roundup of crash reporters, I chose Breakpad because it seems the most similar to Apple’s built-in crash reporter.

Adding Breakpad to your Mac OS X app is easy since the Breakpad team created a Framework around it.

Building Breakpad

Just download the source, open the XCode project under src/client/mac and compile the target “All”.

If you’re on 10.6 though, you’ll need to set the compiler for all the targets and sub-projects to “GCC 4.0″, or else you’ll get an error “GCC 4.2 is not compatible with the Mac OS X 10.4 SDK”.

The default settings for the project (at least as of svn revision 394) create a “32-bit Universal” build. 64-bit isn’t supported yet. See the Breakpad issues list for more details.

Adding Breakpad to Your App

Once you’ve built Breakpad, drag Breakpad.framework into the Linked Frameworks folder of your XCode project. Be sure to check the “copy items into the destination group’s folder” box in the sheet that appears. Also check the target you want to add Breakpad to.

Next, create a “Copy Files” build phase in your target with a destination of “Frameworks”, and drag Breakpad.framework into that.

Next, add a bunch of variables to your app’s Info.plist, including:

	BreakpadProduct
	BreakpadProductDisplay
	BreakpadVersion
	BreakpadVendor
	BreakpadURL
	BreakpadRequestComments

See the comments in Breakpad.h for how to set those variables. One tricky bit: BreakpadRequestComments should be a <string> with a value of "TRUE" in your Info.plist, not a <true>.

As an example, here’s how I set my plist variables for Arq:

    <key>BreakpadProduct</key>
    <string>Arq</string>
    <key>BreakpadProductDisplay</key>
    <string>Arq</string>
    <key>BreakpadVersion</key>
    <string>1.1</string>
    <key>BreakpadVendor</key>
    <string>Haystack Software</string>
    <key>BreakpadURL</key>
    <string>http://crashreport.<yourserverhere>.com/arq/new</string>
    <key>BreakpadReportInterval</key>
    <string>0</string>
    <key>BreakpadLogFiles</key>
    <array>
        <string>/var/log/system.log</string>
    </array>
    <key>BreakpadLogFileTailSize</key>
    <string>40000</string>

Finally, create a Breakpad object in your app:

    BreakpadRef bp = BreakpadCreate([[NSBundle mainBundle] infoDictionary]);
    if (bp == NULL) {
        NSLog(@"failed to create Breakpad");
    }

That’s it! Now crash your app to try it out

On the server side, you’ll need something to process the report. I’ll post my server-side code soon. Tweet me @reitshamer if you need it right now.

UPDATE: I put the server-side code at http://github.com/sreitshamer/breakpadserver.

This would be a powerful way for large enterprises to get around the data ownership issues in cloud computing, especially SaaS-type offerings. But it misses out on many of the benefits of cloud computing.

A hybrid system — let’s call it “Computer as a Service” (CaaS) — could deliver the benefits of cloud computing while mitigating data ownership issues.

CaaS

With CaaS, the “service” part delivers my (virtual) corporate servers, and I pick and choose CaaS-compatible applications to put on those corporate servers. Those CaaS-compatible apps should be auto-installing, self-updating and self-managing.

With this approach I could reap many of the benefits of cloud computing, including:

• compliance best practices — experts handle security, backups, etc.
• no capital outlay
• much less support cost, fewer IT hires
• instant scalability

The service part of this approach could be simply my corporate Amazon Web Services account. A CaaS-compatible app that I buy could install itself on EC2 instances in my account, use S3 for storage and CloudFront for content delivery, etc.

Owned Cloud

I get cloud computing, but I own my data, albeit on Amazon’s servers. And I’ve eliminated SaaS-type dependency because I have the app and my AWS instances in my control, unlike a SaaS offering which may change or even disappear before I’m ready to change.