Categories: Mobile Technology

Platform Fragmentation: Yes, There IS a Good Kind

by Don Sorcinelli Published on: October 2, 2011
Comments: No Comments
Tags: , ,
Categories:Business, Mobile Technology, Technology

The other day, I was involved in what seems to be a regular occurrence for me; a discussion on platform fragmentation. For the non-mobile, non-techie folks out there, this concept refers to the idea that a given platform (say, Android) has aspects about it that open itself up to differentiation. In theory, the differentiation could be a good thing, but usually the term is only discussed when the results are negative (especially for consumer/users). BTW – while I used the phrase “non-mobile”, I don’t mean that the ideas around platform fragmentation are limited to mobile devices. The same thing can apply to any platform.

Well, a couple of interesting thoughts occurred to me during this particular platform fragmentation discussion. First, I found someone in the discussion tried to make an argument that just didn’t fit in defense of the particular platform in question (in this discussion, it was Windows Phone 7.5). The argument was, in essence, that “platform fragmentation” only occurs if the platform causes a given application to work on one device and not the other. I found this argument to be the equivalent of something like changing the dimensions of a soccer field in the middle of a game and then calling everything that was inbounds before suddenly out-of-bounds. It just doesn’t work that way.

From my perspective, I look at a platform from a very gestalt point of view. In other words, the whole of the platform is greater than the sum of its parts. This includes all aspects of the platform. In the mobile world, this includes any OEM relationships, mobile carrier relationships and the ability of the platform (in this discussion, it was the Windows Phone 7.5 OS as a major factor in the overall platform discussion) to allow for customization by the other players in the ecosystem. Remember – unlike Apple with iOS as a platform, there is literally no other “players in the game”; their manufacturing partners have specifications dictated to them, and mobile carriers have no ability to customize other than adding software (and only with Apple’s blessing). Now, with all this in mind, it occurred on me that there can be good aspects to platform fragmentation. The first example came out of the very discussion where someone was trying to change the parameters around what defines platform fragmentation.

A platform that allows for device manufacturers to differentiate through hardware capabilities opens the door for platform fragmentation. However, that type of fragmentation enables:

  • Differing screen qualities
  • Differing audio qualities
  • Integration with other technologies (take DLNA, for example, allowing for streaming from the phone to other devices)

Now, if this particular form of platform fragmentation is allowed without altering the fundamental user experience (something I will touch upon in a moment), then it becomes a “win-win” for both devices manufacturers and consumers. Device manufacturers can compete through hardware and feature capabilities, while consumers have more choice without fear of a differentiator altering expected functionality. The end result – a positive type of platform fragmentation.

From a “bad” point of view, there are in my opinion several major types of platform fragmentation. They include -

  • Allowing for functional changes that break consistent user experiences. The scenario that was positive above becomes negative if a device manufacturer adds or removes capabilities that make application no longer function or change the way users have to perform basic tasks (turning on WiFi, for example). When this happens, moving from device to device within the platform makes for a painful new learning curve and removes the expectation of basic functionality.
  • Allowing for a device manufacturer or carrier to alter the basic user interface experience. Think “skinning” or “theming” here. While there can be an argument (both for and against) allowing users to change the fundamental appearance of the user interface, allowing devices to be sold with this as a default leads to a number of issues, including:
    • Altering the fundamental expectation of user experience;
    • Creating confusion through a lack of recognition of a platform. This was often the case with the old Windows Mobile platform and now occurs quite often with Android devices. Users do not even recognize and cannot identify what platform the device is running, never mind easily perform common tasks. Again, user frustration and new learning curves result when moving from device to device within the platform;
    • Difficulty for the consumer in determining what device is best for them within a platform. The number of returns of devices because of issues like the ones listed above lead to dissatisfied consumers.
  • Creating splits within the platform to accommodate hardware and features. Anyone remember the confusion caused by Windows Mobile Standard (non-touchscreen) vs. Windows Mobile Professional (touchscreen)? How about Android Honeycomb/3.x (tablet-specific) vs. the Android 2.x variants (tablet and non-tablet)? These splits result in software compatibility issues and even greater confusion/frustration for the consumer.

I guess the points I am trying to make here are, quite simply:

  • Platform fragmentation almost always will occur to some level with technology, especially when the technology includes an ecosystem with more than one vested interest.
  • There can be good forms of platform fragmentation that allow for grater choice for consumers without confusing, frustrating or hurting them.

To argue the basic definition of platform fragmentation shouldn’t be the approach when it occurs. Instead, the argument should focus on the benefit or detriment of the fragmentation in question. 

A Message To Prospective Mobile Application Developer Employers

As someone who is regularly directly recruited or asked to refer possible employees for companies looking for “mobile application developers”, I have seen a trend in expectations that I think requires a bit of level-setting. I have a simple message to pass along…

Lower your standards.

While this quote does make me giggle, reminding me of an old Jon Lovitz sketch on Saturday Night Live years back, the statement does have some truth to it. You see, I believe that for many employers beginning the foray into mobile applications, hiring one developer will easily fill the need. Before you go any further, there are some things you should be aware of in order to avoid some disappointment as your hiring search begins.

  • There is more than one mobile application platform out in the world. I find far too many recruiters looking for a mobile developer who, when asked to define which mobile platform will applications be developed for, simply respond “I don’t know” or “does it matter”. The simple answer – “it makes all the difference in the world”. Today, there are several major target platforms your company could target for development – iOS (iPhone, iPad, iPod), Android, Blackberry, Windows Phone. There is not a “one skillset fits all” solution to this situation. The tools, languages and techniques used to fit the development needs all vary (more on this below). As an employer, you should take the time to really refine which platforms you desire for your applications. If you don’t know, perhaps you should first take the time to research your real needs.
  • Each mobile platform requires different technical knowledge. While many concepts around mobile application development are common to all platforms, the actual implementation/development skills around the platforms vary to a significant degree. iOS development requires knowledge of the Objective-C programming language. Android and Blackberry, while both leveraging Java as a language, use differing extensions of the base language. Windows Mobile and Windows Phone both leverage .NET languages (C# and VB.NET), but with significant differences from their desktop and web siblings. The assumption that one developer will be fluent in all languages is a precursor to disappointment.
    To see just how rare the multi-language skillset is for developers, you probably would have to look no further than your current in-house IT group. Just ask any in-house developer how difficult it would be to move an existing desktop application from .NET to Java, or a web application from PHP to .NET. The most common response from a given developer would likely be “I don’t know that language”. While there are always some developers who are fluent in more than one programming language, assuming competency across the board when looking for potential candidates will likely lengthen the time for searching.
  • A “designer” does not mean a “developer” (and vice-versa). Hopefully, most employers and recruiters know this, but I still find some do not. Many developers who are extremely competent at developing mobile applications struggle with user interface design and the graphical nature of applications. Also note that being able to program in a language does not guarantee understanding the nuances of design for the platform. I point this out because of the simple fact that I regularly see employers/recruiters going after general programming knowledge as a way of “fast-tracking” the hiring process. By this I mean seeing companies looking for Objective-C or C# skills and minimizing mobile application development experience. All I can say here is – bad idea. If are comfortable with a large post-hire learning curve for your employee, then you are OK. If, however, you expect instant results, you will likely be disappointed.
  • Be prepared to pay for employees skills. Sadly, there are some employers who are aware of everything I have said thus far but believe by recruiting generally for a mobile application developer they will get a “5 for the price of 1” hiring deal. Sorry folks – just like a company in need of hiring for natural language translation, the rule of thumb is “the more languages known, the higher the price”. Furthermore, the increasing hiring practice I have seen around “don’t tell them what we really expect from them until after we hire them” has resulted in successfully eliminating any employee retention. Bottom line – when you know what you need, be prepared to pay for what you need.

So, what can employers do to successfully recruit and retain mobile application developers? Here are a few suggestions based upon my experiences over the years -

  • Have a mobile development vision before you start the hiring process. By vision, I mean something a bit more substantial than “create mobile applications”. Think about what applications you need, who will be using these applications, what platforms do you wish to target and when you need to go to market with them. This will not only help to define your job requirements; it will also help to engage with hiring prospects during the interview process and best identify hiring candidates. Remember – prospective employees are also interviewing view (not just the other way around). As I have advised many mobile developers seeking jobs, a company that does not understand what they need to hire for or why they are hiring is never a good thing from the employee perspective.
  • Consider hiring tactically and working toward your strategy. This goes back to your mobile vision and prioritization. As an example, your immediate need may be for the iPhone. However, you want to expand your offerings to eventually include Android and Windows Phone. When hiring, you can build job requirements that look for iPhone development up front, but include an interest in developing for Android and Windows Phone in the future. When interviewing hiring candidates, you can discuss their openness toward learning about these platforms. Note: be prepared to develop a plan to support the learning process (training, time to learn, etc) and to discuss this with prospective candidates. There is nothing that turns off a potential development hire quicker than the feeling that an employee just expects them to learn something on their own with no support. By taking this approach, you will be able to identify candidates that are genuinely interested in mobile application development as a career and see you as a company to work with (not just work for) as a career.
  • Remember the non-technical skills in addition to technical skills. Even a skilled programmer in a language and/or platform does not guarantee success if the person being hired lacks “higher-level” skills. As an example, I have heard countless tales of perspective candidates who knew iPhone development inside-out – as long as we were talking games development. For a company wanting to build line of business applications that include domain knowledge and integration into complex enterprise architectures, hiring this person typically results in an entirely different learning curve from both a technical and business perspective. Be sure to include such job requirements up front to avoid a lot of time spent interviewing candidates that don’t meet your needs. Also be sure to include such discussions with candidates during the interview process. I know of at least several instances where candidate screens were entirely focused on low-level knowledge of development, only to discover that the now-hired employee had no knowledge of integrating with business systems.
  • It is a “buyers market”… and you are not the buyer. As hard as this may seem to accept, the demand for skilled mobile application developers is very high, and the supply is quite low. The higher you set the bar for job requirements, the harder it will be to find qualified candidates. Plan for a protracted employee search and hope to be pleasantly surprised if you find someone quickly. Do not wait until the last minute to start a candidate search.

In the end, employers, I give you this feedback and suggestions not to really “lower your standards”, but to adjust them. It will benefit not only yourselves, but the potential candidates to fulfill your employment needs. I just couldn’t pass up on the Jon Lovitz reference, though Winking smile

Platform Fragmentation Doesn’t Just Hurt End Users, You Know…

I was just noticing all the tweets and Facebook posts the last few days around Android devices and “haves and have-nots” with regards to operating system updates. Of course, a lot of the focus on peoples’ posts are very personally focused (“I want…” or “I need…”). This is all well and good, mind you. However, there is a whole other group of people who are having to wrestle with the kind of platform fragmentation that Android seems to be experiencing – IT folks who support large numbers of corporate workers. Sadly, this seems to be a case of “here we go again” for many of these folks.

As someone who has worked with mobile device in the enterprise for a number of years, I can’t tell you how many times fragmentation has created havoc at the enterprise level in terms of providing users support or even access to enterprise systems (email, IM, file access, etc). Early on, it was just the expansion of platform variety that caused the problems. Today, it is nearly impossible for a business to simply say “you have to have <device x> in order to get…”. I have witnessed countless businesses who tried this approach, only to have to later change direction from too much pressure from executives and workers. Supporting multiple device platforms, however, was only the beginning.

Windows Mobile (or so it was named back in the day) was the first mobile OS that I worked with that had fragmentation within a single platform. As a matter of fact, it suffered at times from “fragmentation within fragmentation”. You see, there was the “Smartphone” version of the platform (eventually this became known as the “Standard Edition”) and the “Pocket PC” version (eventually known as “Professional”). Each had different capabilities and limitations. Some of these impacted developers creating applications, while others affected IT organizations trying to secure and configure devices to meet business guidelines. Add to all this confusion new versions of the operating system that often did not reach existing devices (mostly due to device manufacturers and carriers not wanting the updates to see the light of day), and the Windows Mobile platform was a constant source of confusion for IT support. Amazingly, I now look at the current state of Android and I am feeling a strong sense of history repeating itself, this time with Google playing the role of Microsoft. There are a couple of reasons for my thoughts here.

First, you have the breakneck pace of Android releases. This is actually happening at a far quicker pace than Windows Mobile updates ever happened. Each release introduces new features. Google has started to also take into account enterprise needs as well, with better Microsoft Exchange server support (including mailbox policies). This is great on the surface, but now factor in the device manufacturers and carriers once again taking their time to release the new OS versions to users and – well, here we go again. Add to this Google’s recent inferences that Android 3.0 is a “tablet-specific” OS and my brain immediately thinks “Smartphone/Pocket PC” all over again. Most amazing to me – Google seems to be oblivious to the risks that this current situation brings forth.

Microsoft’s mobile strategy was by and large the undoing of Windows Mobile, in my opinion. While there was a lot of user dissatisfaction around the operating system, Microsoft eventually lost the backing of the enterprise. Corporate IT was a major backer of Windows Mobile for quite some time, with the combination of enterprise-focused functionality and tremendous configurability and security options making it the “phone of choice” for many organizations. The fragmentation issue became too much to deal with over time, however, and when coupled with pressures from the user base led many IT folks to submit. Windows Phone 7 is the ultimate testament to the problems of Windows Mobile – it is a platform wholly-focused on avoiding the platform fragmentation issues of the past.

Android seems to be rapidly moving to a situation where the combination of user dissatisfaction over the lack of OS updates and IT frustration over the complications created by platform fragmentation could find Google witnessing some serious abandonment. Mind you, the question here is not about how good Android is as an operating system; it is about how good the platform and partner ecosystem are. As a developer, I have often reminded people “even if you have created the greatest application ever written, without user and IT acceptance it is nothing”. Google needs to be very careful of the path they are following – the path has led to a dead end in the past, and there is nothing to prove that history won’t repeat itself.

page 1 of 1

Welcome , today is Wednesday, February 22, 2012