We’re hiring a NON-developer

Over at Oasis Digital, we are in the (job) market for our first non-developer, non-project-manager, non-service-delivery-focussed full-time team member. The job post is on the Oasis Digital site; I thought I’d write about a bit more about the story here.

Part of the challenge of running a software development consulting firm, is the tension between:

1) Focus on Customers You Have Now

Some firms are so service-delivery centric (#1 above), that they don’t bother to address the rest of the world, i.e. all of the not-customers-yet. Small consulting firms are especially vulnerable to this, and as a result they stay small.

Historically, Oasis Digital started in this category, with long-term projects, satisfied customers, and slow/organic growth. The shape of our organization reflects this: everyone, including me, works mostly on creating software for customers.

2) Focus on Customers You Want to Have Later

Some other software firms are highly marketing-driven, to the extent that their service delivery value proposition (in terms of design, features, and quality per customer dollar spent) suffers. Large technical service firms are especially vulnerable to this. Anyone who has been around the block a few times, has experienced the unique joy of a very large sum spent with a very large vendor to deliver sufficient, but disproportionately expensive, results.

Turning Up the Heat

Our goal and challenge now, is add a bit of focus on future customers (which is to say, marketing, community participation, etc.), without losing our service delivery mojo. To move things in that direction, we need at least one person who is not occupied by service delivery… hence our upcoming hire.

We will also quite likely start another software product or SaaS business along the way. (I’ve been there before, of course, and did plenty of hiring and business development work along the way.)

Some Things Won’t Change

Since inception, our sales process has been decidedly non-traditonal:

  • We encourage potential customers to meet their needs with off-the-shelf software, not custom software, if possible.
  • We don’t have commissioned salespeople. Nor commissioned pretend-they-aren’t-salespeople.
  • Most of our team is, and will always be, all about delivering great results for our customers.

I’d love to receive feedback on this, from those of you with experience in this particular transition. You know how to reach me.

Update: We’ve filled the need for that job post, with a combination of a few people, rather than a single jack-of-all-trades as I had planned.

The Much-Discussed Apple iPhone 4.0 beta TOS

As I write this in April 2010, Apple has just released a beta iPhone 4.0 SDK with the following rather alarming addition to the legal terms (at least according to many web sites; I haven’t seen it directly from Apple yet):

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

The is an avalanche of commentary out there on this, most of it negative, centered around the word “originally”. John Gruber, in his second comment about section 3.3.1, gives some reasons why this is sensible from Apple’s point of view. The essence is that it will lead to higher quality app, on average.

I will try to add a bit of insight from my experience. I am of two minds on this.

Why It Makes No Sense

From the point of view of using / creating the best tools, it strikes me as ridiculous. Great developers, or developers creating great things, generally use layered software designs to do so; and indeed layering, the increase in abstraction over time, is absolutely crucial to the software industry’s ability to make good use of ever-growing hardware capabilities. One obvious and vital kind of layering/abstraction is the use of higher level languages. Apple’s new insistence that only its provided languages/runtimes be used, ignores this fundamental insight.

More ominously, if this notion of “originally written” turns out to be enforceable. Imagine if earlier platforms had required that all software be written “originally” in the provided languages, with any attempt to build a higher level on top, banned; we could never have gotten to the amazing variety of technology available today, under such a regime. If such restrictions grow popular beyond Apple, that could lead our industry in to a kind of dark age.

I don’t think that’s likely though, and for that matter I think it is most likely that Apple won’t be able to make this new term stick. There are many successful apps already using a variety of languages, frameworks, and layered designs. Enforcing it as written, universally, would impact too many of those. Yet if Apple enforces it selectively (just to squash Flash, as many commentators suggest), they invite a long and painful legal mess. Speaking of that, such a legal mess would be an enormous windfall for Android.

Why It Makes a Bit of Sense

Setting aside the questions of whether it can possibly work, Apple’s notion does make a some sense, at least for the immediate future for this specific (iPhone etc.) platform. Most iPhone users/customers are probably better served by a market consisting mostly of native apps.

The difference between native and non-native apps for iPhone OS, is mostly analogous to the same difference a decade ago in PalmOS software. The native (and tedious to use) C toolset was the most popular, but there were many other (higher level) tools to choose from, and with frank honesty I can say that the results were generally poor, and almost always worse that write the same app with the native tools.

In fact, my firm Oasis Digital worked for at least two different customers on projects to replace applications written using such tools, with code we wrote in C or C++. Yes, it took longer; yes, it was more lines of code. Yes, it took more testing and was more prone to the kinds of problems low level code has, with memory leaks and the like.

But most critically, from the point of view of the users, our results with low level tedious implementation were obviously better. The high level tools available today for iPhone are much better than the Palm stuff a decade ago; but still, I suspect the same applies to a lesser extent on the iPhone-OS platform today.

Apple, Cut That Cord

As I think back to opening up my new iPad, two things stand out. First, the product packaging is delightfully minimal. It does not even contain media with the iTunes software, instead explaining that the first step is to download iTunes.

Second, a new iPad does not work at all until syncing it with a PC (Mac or Windows) via the included USB cable. I find this surprising because, in so many other ways, the iPad is a great device for someone who wants access to basic computing capabilities (web, email, casual games) without caring about the complexity of a PC. Yet such a user must already have a computer, with all its (potentially very-un-Apple) complexity, to use an iPad. The polished experience is potentially debased by being plugged in to a $200 closeout PC, just to get it running.

The need for iTunes seems quite justifiable in smaller Apple iDevices; but for the iPad, I can’t help but notice its specs are ample to be self-contained.

Even for those of us who will sync to a PC, why the cord? The iPad has WiFi and Bluetooth, as do most PCs nowadays. Plugging in that wire to sync seems utterly antiquated. Apple could could scrap that many-pinned proprietary port, and replace with a much simpler power plug, which would also free it from the pitiful rate of charge provided by USB. An iPad could have a MagSafe charger, and charge up more safely and in 1/2 the time.

Apple, cut that cord!

My iPad is (unfortunately, mostly) a toy

Some pundits have declared the iPad a “toy”, or suited only for content consumption. I disagreed with the latter a few days ago, and I think it will have some very interesting business uses. If I come up with a sufficiently novel one, Oasis Digital might implement it.

But sadly I must mostly agree, for at least my personal use of iPad v1, with the “toy” assessment. Here’s why.

I like to hand this iPad (I wrote the first draft of this post on it) to other people to try out, to my kids to play with, to sit it out as a novelty for guests, etc. But if I set it up as a personal tool, with my email, calendar, Twitter, Facebook, other accounts, work related files, etc., then I’d be handing access to all that personal and business information to everyone I offer the iPad to. Clearing out and re-entering my accounts from a whole pile of apps (and Safari, and Mail, and ???) is tedious and error-prone. My personal accounts include occasional bits of my (and our customers’) proprietary information, so leaving them present for guests is clearly unacceptable. Thus, for now this iPad can be only a toy to me. I occasionally set up email, then remove it; set up Twitter, then remove it, etc. I type some notes, then email them to myself, and remove them.

The key missing feature of the iPad, for me, isn’t a camera, a USB port, or an SD slot – it is the lack of a user account/profile capability. My Ubuntu netbook, at half the cost, has this capability in the box.

This isn’t much of an issue with an iPhone, which by nature of being a phone, is inherently almost always a personal (not shared / guest) device.

This isn’t much of an issue with an iPod Touch, at least for me, because I already use it as a guest/toy only anyway.

I suspect that Apple won’t add an account/profile mechanism anytime soon; it is easier to therefore ignore a mixed personal / guest use case like mine. If Oasis Digital ends up with a line of iPad software, we’ll work around the problem by buying more iPads.

But in the meantime, I like the share the one I have – so I must configure it primarily as a toy.

iPad: Not Only for Content Consumption

Like 300,000 other people, I have a shiny new iPad in hand. Here is my very short review:

Apple is going to sell a huge pile of these things.

Expanding on that…

Lots of other companies are going to sell an enormous pile of apps for the iPad. From the point of view of a maker of software, this is a very appealing market. As with the iPhone before it though, my main concern is that it is such an appealing market, that is might actually have an unfavorable ratio of developers to customers.

Other hardware and software makers are either in panic mode, or they should be and will suffer if they aren’t.

The device and its software are remarkably polished and ready for wide use, primarily for content consumption. There are many commentaries out there about the iPad as a device only for consumption, citing the lack of a keyboard and camera among other factors. While the lack of a camera in iPad v1 is a bit annoying, I expect that to be fixed in the next version (2011?). Regarding the keyboard, I am also a fan of physical keyboards, but I was able to write the first draft of this post on an iPad without much difficulty. It is clearly unsuitable for writing many pages of text or extensive editing, but quite sufficient for blog posts, tweets, organizing and naming photographs, short emails, and many other minor-data-entry tasks done every day.

On the other hand, I generally agree with the many comments out there about open vs. closed systems, and I am a fan mostly of the former. We are in a situation right now where is one particular closed system has a great lead on the open alternatives, a situation I expect to continue for a few years but not much longer. The hardware design needed to make the iPad work is currently an area where Apple is well ahead of its competition; but they will catch up. Android devices with a similar form factor, battery life, and somewhat-as-polished user experience will appear.

The biggest surprise so far is Pages – it works much better than I expected (which was admittedly a low bar). A related annoyance is that Pages documents don’t automatically sync in iTunes; rather iTunes provides a GUI by which I can manually copy Pages files back and forth.

The second biggest surprise is my impression of the size of the iPad. I had expected it to feel a bit too small; instead, I think it’s actually a bit too large. I wouldn’t be surprised to see v2 feature a screen 1/2 inch smaller, and overall size 1 inch smaller.

As I expected, for me an iPad is an adjunct to my real computers. My work involves extensive use of multitasking, keyboard, pixel-accurate mouse positioning, large hierarchical collections of files, and all the other things that modern “real” computers are well suited for. I don’t see this as problem for the iPad though; for it to succeed, it is not necessary for grown-up computers to fail. It doesn’t even need netbooks to fail.

Lastly, it has been observed that iPad use requires a knees-up sitting position, and I can confirm this is true. There isn’t a good way to rest an iPad and have both hands free to use it, while tilting it to a reasonable viewing angle, other than with one’s knees up.

Why Choose Custom Software?

To meet the software needs of your business, there are two main paths:

  1. Buy software “off the shelf”
  2. Build custom software (in-house, or with a development firm)

In most cases, off-the-shelf makes the most sense, and it should be your default choice:

  • Acquiring and deploying off-the-shelf software is usually faster than getting custom software developed. Even complex installation and configuration it typically faster than developing new software.
  • Off-the-shelf software is generally cheaper than developing your own. The development cost of an off-the-shelf package is distributed among multiple firms, possibly many firms worldwide. These many customers more than offset the extra cost of mass production and distribution. Comparatively, with custom software your business alone bears most of the costs.
  • Off-the-shelf software typically has years of testing and years of production use, as well as feedback and improvement, giving confidence that it actually works.
  • Off-the-shelf software may include a money-back guarantee in case it does not meet your needs.

For all these reasons, the option of designing custom software bears the burden of proof in your decision-making process.

There are good reasons, though, to consider custom development, especially in mid-sized or large companies. Under the right circumstances, these advantages can make the decision to develop software the best choice.

 

Read the rest on the Oasis Digital blog.