10 Ways To Doom Your Next Mobile App - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Software // Productivity/Collaboration Apps
News
8/16/2016
07:06 AM
50%
50%

10 Ways To Doom Your Next Mobile App

There are many ways to mess up mobile app development. These 10 will get you to #fail the fastest.
Previous
1 of 11
Next

(Image: WaffOzzy/iStockphoto)

(Image: WaffOzzy/iStockphoto)

We all live in a mobile world now, and the mobile world needs apps. You might be an IT professional working at a startup looking to find success on the back of an app that goes viral.

You may work at a multinational corporation, building apps for your business units to use in their work processes. No matter what your industry, if you're an IT professional, the odds are pretty good at some point you'll be called upon to build a mobile app.

There are an awful lot of ways to get mobile app development very, very wrong.

The effects of a bad mobile app can cascade far beyond the edges of the IT department, catching business processes, business units, executives, and customers in a roiling avalanche of fail.

To help you avoid such a fate, we've devised this handy list of 10 ways to kill your next mobile app. Here's the thing: As you go through the list you might well find yourself saying, "My development group would never do anything like that."

You might be right. But most of the bad practices we highlight here aren't the result of someone walking into work one day determined to fail in the most spectacular possible fashion. Most of these are the result of one completely reasonable decision after another that happen to lead down the path of development disaster.

[Federal agencies now must share code. Read Federal Source Code Policy Requires Agencies to Share Code.]

As with most lists of this sort, practically none of these problems can be put down to issues with the tools. "If only we'd chosen C++ instead of Java we never would have required 34 separate clicks to buy a roll of stamps," isn't likely to be part of anyone's real-life conversation.

No, the real disasters in mobile app development tend to stem from human decisions and processes that break down. In either case, the responsibility for fixing the problem comes back to humans. That's the good news.

It's good news because it means you can learn from the mistakes of others and free yourself and your department to make bold new mistakes. You won't set out to make mistakes, and they're not inevitable.

It's nice to be aware of, and guard against, the bad practices on this list. There will almost certainly be a positive bleed-over that helps you guard your processes against some of the creative screw-ups possible when you're trying to fit a large enterprise application onto a 5-inch screen.

These bad practices come from a variety of places, including my own conversations with development managers, discussions on the web, and my own experience as someone managing developers. The thing I'd like to add to the collection is your experience.

Once you've reviewed our paths to failure, tell us which of these seem like real problems to you. Which have you had the misfortune to experience? Have you see other spectacular ways to fail at mobile app development?

I'd like to know about your experiences, and what you would do to avoid ever having to walk through that particular scree-field of development-failure in the future. The comments section below is open -- I'll see you there!

Curtis Franklin Jr. is Senior Analyst at Omdia, focusing on enterprise security management. Curtis has been writing about technologies and products in computing and networking since the early 1980s. He has been on staff and contributed to technology-industry publications ... View Full Bio

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Previous
1 of 11
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DDURBIN1
50%
50%
DDURBIN1,
User Rank: Apprentice
8/17/2016 | 12:03:47 PM
Time vs Cost vs Qualtiy
Pick any two and the third will suffer. In my experience management is in denial on this concept most of the time particularly when the "features" list runs the lenght of the building and down the street changing from week to week. Expectations are all can be delivered and done perfectly at a fixed time at a fixed cost no matter the number of features added after the project gets started.
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

News
Remote Work Tops SF, NYC for Most High-Paying Job Openings
Jessica Davis, Senior Editor, Enterprise Apps,  7/20/2021
Slideshows
Blockchain Gets Real Across Industries
Lisa Morgan, Freelance Writer,  7/22/2021
Commentary
Seeking a Competitive Edge vs. Chasing Savings in the Cloud
Joao-Pierre S. Ruth, Senior Writer,  7/19/2021
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
Monitoring Critical Cloud Workloads Report
In this report, our experts will discuss how to advance your ability to monitor critical workloads as they move about the various cloud platforms in your company.
Slideshows
Flash Poll