Are We Really Mobile Developers Anymore?

August 1, 2010 John Blanco Mobile

As developers, we tend to be categorized by our specialties:

There are backend developers, those who work with databases and scalable architectures with systems like Java EE or .NET.

There are Web developers, those who either specialize in PHP, Rails, and Django or perhaps HTML, CSS, and JavaScript.

There are frontend developers, specialists in the UI. Flex, Silverlight, Swin–*cough*–Swing…and we even sometimes refer to Web developers this way as well.

Then there’s the Mobile developer. We work with iPhone, BlackBerry, Symbian, Android, Java ME, and whatever Windows phones remain on the planet.

Five years ago, I could give you a long list of reasons why I’d be more qualified to take on a new mobile project, even if it was a new phone technology I was unfamiliar with. When the iPhone was released in 2007, I knew I was more qualified than any other non-mobile developer to take a stab at writing an app. It wasn’t that I knew iPhone (or Objective-C, or even Mac!), it was that I knew mobile. I was a mobile guy.

Here’s a long list of qualifications that I believe defines the classic mobile developer:

• Writes code in a low-memory environment, handling more common out-of-memory errors and creating low-memory algorithms.
• Writes highly optimized code that runs efficiently on low-performance devices.
• Writes applications that can target a diverse set of devices that may include black & white vs. color screens, tiny to moderate amounts of RAM, differing platforms such as MIDP1 vs. MIDP2 or CLDC1 vs. CLDC1.2, etc.
• Writes software for a platform other than the machine they’re developing code on.
• Has the knowledge to install applications in a variety of ways depending on individual platform requirements. (USB, Over-the-Air, serial cable, etc.)
• Writes software on obscure platforms like Java ME, Windows CE, or the hybrid BlackBerry API.
• Able to code to multiple API’s at once, for example when GPS was still being standardized and you had both JSR 179 and private API’s for varying phones that produced varying results. (Good luck with device coverage back then!)
• Able to design an application that can be built by multiple SDK’s simultaneously.

There’s more, but let’s stop here. Hopefully we can agree that these qualities are what allowed us to identify a mobile developer as such.

Something’s changed, though. It happened subtly. Back in the “old days,” phones came and went quickly, all with their own private API’s, and the technology was improving rapidly. We saw Java phones, BlackBerry’s, Windows, tons of manufacturers like Symbian and Samsung and all the PAYGO phones.

Nowadays, things have slowed down.

The New Mobile Developer

In the last three years, the mobile landscape has been dominated by just three platforms: iPhone, Android, and BlackBerry. I exclude Palm from this because, well, no one has a Palm. (BURN!) And I’m eager to drop BlackBerry as well because RIM has always been awful at cultivating a development community. There are plenty of other phones, and some, like Symbian, still control major portions of the market, but we all know that’s going away soon.

Over these three years, we’ve seen iterations of the iPhone along with iterations of their SDK. Even when the iPad was introduced, the SDK was almost exactly the same, and you could build for both iPhone and iPad easily. When the iPhone 4 was released with a higher-res screen, they made sure is was exactly twice the size. Not only was it simple, you retained all your skills and didn’t have to deal with a new, custom SDK.

Android phones have come out in large droves as well. While I predict that Android-powered phones are breaking the market up into so many pieces that developers will soon flock in droves away from the platform, it’s still an important one today. (Java ME developers know what I’m talking about — that feeling of wanting stab yourself with something very sharp come deployment time.)

The iPhone benefits from modern software modules. Remember the past when you needed an XML processor and you were forced to choose from libraries that might be called MiniXML or TinyXML? Not anymore. I remember spending DAYS trying to find a SOAP library for Java ME. I ended up having to roll my own. :-( Today, most of the Mac libraries used for desktop development now work for the iPhone untouched.

The same goes for Android. The limitations of Java ME made using modern Java libraries impossible, and there simply wasn’t significant demand to have them all re-written. Android has more power, and with it, most Java frameworks can be installed on the phone without issue…and if there is a problem, there is significant motivation to make it so. And it’s easy to do compared to doing it for Java ME.

Also, thanks to these new phone lines, low-memory and low-performance considerations are fading away. Play with an iPhone 4 for just a minute and tell me that you’ll need a mobile developer to be able to write software for it. HA! It runs faster than my laptop did just 5 years ago. (Not fair, that was a Windows machine.) Any serious developer can take their turn at it. Finally, quality software and competition is at the forefront, not fringe software availability.

You see this difference every time you look for an application for a favorite website of yours, and are literally outraged if it’s not there. “How could they not have an iPhone app??” You had zero expectations when you had your free Java phone.

I’m a Mini-Frontend Developer

For the sake of marketing, I do consider myself a mobile developer. I advertise as such and I regard Rapture In Venice as a mobile solutions provider. But, is the work I’m doing similar to what it was a few years ago when I was pumping out Java ME and BlackBerry apps for my clients? Certainly not. The only difference between me and a Mac programmer is a resizable window bar.

Is Good Code Impossible? Is Good Code Impossible? Part 2: Project Manipulation Patterns