What's Wrong with Mobile Development and How to Fix It

Between the proliferation of mobile devices, the differences in operating systems, and the complexity of application interactions, mobile developers are often caught between the desire to ensure robust functionality and the need to contain costs and meet deadlines. 

Do we code for the most popular devices and hope for the best? When we can’t stay abreast of releases, do we schedule updates less frequently than hardware, firmware, and OS developments would suggest?

Do we not worry about overloading our apps with web services that create data nightmares, or do we write intermediary web services to keep them in check? When users want full integration with back-end systems like enterprise resource planning (ERP) platforms, do we provide the minimum functionality and kick the rest of the coding down the road, hoping for a bigger budget in the next release?

While the answer to these questions may often be “Yes,” most developers realize such an approach is not a sound strategy. Given astronomical user expectations, reducing quality or usability to save money or time initially only results in user disappointment - and invariably increases costs when the complaints come rolling in, post-release. Yet, many companies continue to follow these methods.

The reason, at least in part, is that there has historically been no affordable, easy way to code for 10,000 devices, effectively manage thousands of web services, ensure complete integration with back-end systems, and resolve other challenges. The good news is that modern tools can largely automate the most onerous of these processes, creating a dramatically different paradigm for device development.

When I said “automate,” some of you may have thought, “Oh, yeah, now Joe is going to lecture us about test automation or virtualization.” Although Orasi, as a quality assurance leader, fully supports such approaches, the tools to which I refer take the stage much earlier - during the development cycle.

There are several contenders competing in this space, and Orasi has recently partnered with one firm, Kony, whose tools surmount some of the greatest challenges to good development. Other providers in the space include Telerik, IBM, and Xamarin.

One area where developers face excessive effort is with user interface design. As the media consistently remind us, today’s users have incredibly high expectations for application features, and they are very vocal when they are disappointed. (Last month I mentioned #appfail, and one look at the Twitter feed for that hashtag alone illustrates this point.)

One of the traditional components of defining functionality for user features, of course, is manually scripting event handlers. With a complex application, that can be a tall order in terms of both time and resource allocation. Newer solutions help to automate this process.

We have identified a solution that offers a WYSIWYG interface for mobile phone, tablet, and desktop app design, enabling developers to define user experiences including navigation, animation, and even deep device capabilities, without writing a single script or line of code. All the team member has to do is write the business logic, and the tool does the rest. (It also offers real-time app previews prior to moving into the build.)

Perhaps the biggest single challenge in today’s development market is cross platform development. See if this scenario sounds familiar. The business analyst or organizational stakeholders determine that developers should build the executable for the device and OS common to the most users (employees or customers), such as iOS 8.

Then marketing comes in after the build is released to production (or live in users’ hands) and says, “Oh, we need it for Android - specifically, Samsung Galaxy 4, 5, and 6, too.” Development teams go back to the drawing board, this time with Java coding, writing new code bases and building the executables for these devices, as well.

When it turns out even later that a significant portion of users are still on Samsung 3 and iOS 7, or that the app needs to be deployed for Windows or BlackBerry also, more coding ensues—or the organization simply ignores a portion of its customer base. The result is a significant expenditure in resources, not to mention a strained delivery timetable. However, until recently, there was no reliable way for developers to enjoy ”code once, deploy many” functionality.

Today, programs are available that enable teams to write and test code for one device and OS edition and then have the program automatically revise the code and generate the executable for additional devices. How many devices are supported, and how successfully it addresses all of them, depends upon the solution.

Orasi works with a firm offering a Java-based product that enables automated builds for up to 10,000 different device, firmware, and OS variants. To start the process, one team codes and builds one executable in Java, and the platform takes it from there. When new releases come out, the solution provider issues code updates, and platform customers can push out the updates with the touch of a button.

Interaction with back-end systems can be a big headache, yet organizations are clamoring for it. Everyone wants mobile apps that can talk to and exchange information with ERP platforms and other back-end behemoths, not only for external stakeholder communication but also for interaction between departments within the organization.

Traditionally, developers wanting to integrate their apps with back-end platforms have needed to engage in custom scripting for application programming interfaces (APIs) and other integration components. The rise of back-end as a service (BaaS) and mobile back-end as a service (MBaaS) are revolutionizing back-end integration.

These services simplify the process for app developers to permanently link their apps to back-end platforms by negotiating the secure connection and pre-authorizing it, allowing secure content exchange when the app provides a token or passkey. These applications may also support enhanced features such as push notifications, integration with social networking services, and more.

Some of these tools require customer development of software development kits (SDKs); while the best of them have the necessary information and logic built in to achieve developer goals with no custom programming.

The fourth area were we see a real pain point is with web services. Web service connections have become ubiquitous, persistent components of app functionality, and that is not going to change soon, if ever. However, apps often must deal with excessive “chattiness” when they receive responses from the services, which often include far more data than is actually needed. This sucks bandwidth, consuming data allowances and slowing response times.

The goal, then, is to find a way to redefine the data pipeline so the response to the app is precisely the data that it actually needs. MBaaS tools can be valuable here, as well, acting as intermediaries in the exchange and handling the refinement process.

For example, let’s assume a call to a web service might normally produce 500 fields of data, but the MBaaS tool has a parameter that identifies the six fields the app actually needs. Acting as the intermediary, the MBaaS tool can return only that information.

The only way for a developer to produce this result, normally, would be to write a separate web service to perform that data refinement, which increases both development burdens and application complexity. Programmers would have to write a different service for every data combination needed.

Ideally, the MBaaS tool would also be able to synchronize data offline. For example, if a user is retrieving a shipping quote, then steps into an elevator and loses his connection, the cloud-based MBaaS tool should be able to continue working with the web service to acquire the information, and when the user reconnects, it will update the information on the user’s device.

Synching of offline data is one of the hardest things for a developer to write, yet this feature has a high “wow” factor with users. As a result, we view MBaaS as one of the “low-hanging fruit” of modern development tools, in terms of achieving payback.

Although I personally favor Kony as a solution of choice, I encourage all organizations and their teams to conduct thorough research into the new crop of development tools. For the greatest return on investment, firms should identify and license those solutions that automate functions implicated in the greatest resource, time, and/or quality drains.

The overriding point is that the entire development landscape is being revolutionized by this new breed of tools, and some are fully matured and producing results, now. In fact, if you are a developer or development team leader excited by all this potential, but who envisions a battle with the “bean counters” over budget, let me offer this closing tidbit. 

These solutions are poised to help firms get apps to market faster with a lower total cost of ownership, and the best of these vendors can prove it.