There are more gotchas in software than in professional politics, unfortunately.  Some are a lot more serious than others and some are downright unforgivable.  I've found the lynchpin for mobile development to be, not in the app itself, but in the supporting services.

Not all apps require services to communicate back to the server, but in a corporate environment, 99% of the time they do.  This is where the problems arise.  Most mobile developers are so focused on user experience that they have blinders to anything that exists other than their app.... it's the only thing in their ecosystem, as far as they're concerned.  In reality, the mobile app is just the tip of the iceberg.  It's an old analogy, but think about a corporate system being one large iceberg with many points that stick out of the water.  At the surface, it could appear to be multiple icebergs moving freely, but underneath, it's all the same mass.

The typical mobile developer has discipline in only one thing... mobile user interface design.  To develop a corporate app it is important that you look at the complete system from the perspective of an architect.  This is where a background in software architecture and a lot of experience comes into play.  The mobile developer is just another developer under the umbrella of software engineering - a cog in the larger machine.  When starting a mobile project, it is important to hash out the supporting web services first - not to design the app and drive the services from the app.  Services should be based on solid use cases and user stories.  When done well, the app will manifest naturally.  A matter of fact, doing it this way makes it simpler to add on different mobile devices or web clients later on.

Over the past three years, I've seen a lot of examples of mobile projects that have failed. The failures occured for a number of reasons.  A common, primary reason for failure is money/budget.  Many folks have an unrealistic expectation of what a mobile app should cost.  There is a misconception that because it is smaller, it should take less code and/or be easy to create.  Simplicity on the front end doesn't always equal less complexity on the backend.

Another reason projects fail is a lack of experience in overall system architecture.  For example, a company hires a developer who has a nice shiny portfolio of self-contained apps with no backend in the app store with the intention of building a corporate, enterprise app.  The developer is quickly in over his or her head due to a lack of experience dealing with web services or complex corporate integrations.  The developer is usually the cause of this failure because almost always the cost of the app is underestimated to the client at the beginning, which leads to problem #1 above.

There isn't anything wrong with being an enthusiastic young developer and loving mobile apps.  Lots of mobile developers these days are in their early to late 20s and have no software experience outside of web site design.  Don't get me wrong, I'd hire a smart energetic mobile developer just like this in my enterprise, I just wouldn't put them to work designing an enterprise system or doing requirements gathering and estimation without serious oversight and collaboration with a more seasoned and experienced resource.

Here are some tips to help you choose a mobile developer, if you plan on finding someone to do an end-to-end mobile solution for you.

• Ask the mobile developer for a resume (seems like a no brainer, but some people don't ask).
• Ask the mobile developer about apps they have done for corporate clients (if they don't have any, you might want to pass).
• Ask them for examples or a demo of their current work (in particular, apps that maybe resemble the types of functionality you want in yours, for example, offline capability, data storage and service communication).
• Look at their past clients. Are they enterprise clients or small business?
• Beware the gamers and 3D junkies. The type of developer that is focused on writing games and likes integrating 3D features into an app usually isn't the right fit for an enterprise application. This pairing usually ends in deep frustration for both parties.
• Look at how many apps they have submitted to the app store and what each app does. If the body of work is mostly app store submissions with apps that don't require an internet connection, then you might just have someone who may not be a good fit for a doing enterprise level work.
• Ask for the timelines it took to develop some of their apps and then ask for a ball park estimate at a high level for what you want to do. If the number seems to good to be true... it is.

By no means are these tips absolute, but they are good starters to get yourself acquainted with a candidate.

A good enterprise mobile design should be flexible.  It should have the ability to support mobile interfaces or web interfaces without having to change the back end.  This is the essence of interface-driven design.  The backend code should be written by someone with plenty of experience in service design.  Proper expectations should also be set from the start.  Having a great mobile developer with a talent for interface design is important, but keep in mind, it is merely one of those little points of the iceberg sticking out of the water.

Google+