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 Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... 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: Ninja
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.
Slideshows
What Digital Transformation Is (And Isn't)
Cynthia Harvey, Freelance Journalist, InformationWeek,  12/4/2019
Commentary
Watch Out for New Barriers to Faster Software Development
Lisa Morgan, Freelance Writer,  12/3/2019
Commentary
If DevOps Is So Awesome, Why Is Your Initiative Failing?
Guest Commentary, Guest Commentary,  12/2/2019
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
The Cloud Gets Ready for the 20's
This IT Trend Report explores how cloud computing is being shaped for the next phase in its maturation. It will help enterprise IT decision makers and business leaders understand some of the key trends reflected emerging cloud concepts and technologies, and in enterprise cloud usage patterns. Get it today!
Slideshows
Flash Poll