10 Ways To Doom Your Next Mobile App- Valutrics
There are many ways to mess up mobile app development. These 10 will get you to #fail the fastest.
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.
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?
Build In Too Many Features
We’ve all been in those developer meetings. You know, the ones where everyone looks at the application’s purpose and starts throwing out features to make it better. Then comes the magic moment when you look at the list of possible features and decide each and every one deserves a place in the app. Hey, you’re using an agile discipline so you’ll sprint your way to the most full-featured app ever, right?
This decision is where the wheels start to come off your app development effort. There’s nothing inherently wrong with an app that has all the features necessary for the work flow in question. But it’s better to be ruthless sooner rather than later when it comes to focusing your effort and pruning extraneous features. If additional features become necessary later, then you can add them as part of the agile process, or even create another app focused on those features. Keep things focused and you’ll greatly increase your chances of creating a winning app.
Reuse All Your Old Code
There’s this big new coding effort getting started and the deadlines are tight. Why not dive into the archives to pull out all the existing code possible for your project? Remember the routine you found so helpful four years ago? Bring it on in! Code is code, right? Now is the time to put the whole “platform independent coding” theory to the test!
OK, slow down, Sparky. Yes, reusable code is important. But it’s also important to remember how technology and coding frameworks change. Sometimes, new ways of doing things happen for a reason — like vastly improved methods or technology. Sure, look at reusable code, but do so with a critical eye. Simply because the code exists in your repository, there’s no requirement for it to be used in this project.
Give Developers And Designers Different Goals
Your designers and developers don’t really get along all that well, do they? If you want to keep the project running smoothly, it’s probably best if they don’t get together all too often. This is what your beautiful project specification and documentation system is all about — except your developers really know what the users need, so they’ll modify the specs when required. No need to trouble the designers with internal change orders, right?
Here’s the thing: Designers tend to know what they’re doing. Developers tend to know what they’re doing. If they’re both working toward the same goals, they can get an awful lot done. It’s when they’re working under a single project title, but each is actually working on his or her own project, that things get complicated and results get bad. Bring your designers and developers together early and often. Make sure they agree on what the project is and how to get there. Then make sure any disagreements are hammered out in meetings, not in quality control.
Pretend All Platforms Are The Same
When we build an app we want every user, everywhere, to have the same experience. So it’s entirely cool to design our user interface to be exactly the same on every platform, right? Doing so will let our programmers use a lot of the same code, which means the project will meet deadlines and everybody will be happy, right?
Wrong. While you do want users on different platforms to have similar experiences, each mobile platform has its own accepted user interface practices upon which users depend. Trying to force Android users to do things the iOS way, or vice versa, will lead to users who are less happy and less productive. The same applies to programming.
The only real “write once, run anywhere” code is one that allows the software framework to handle user interface issues. Make it simple for everyone: Plan on parallel development efforts so that you have two (or more) successful apps come out at nearly the same time. Everyone will be happier.
Have One Team Write For Multiple Platforms At Once
Speaking of parallel development efforts, let’s get something out of the way pretty quickly: People don’t multitask worth a darn. If you only have enough staff for a single development team, either break them out by platform or wait and do one app at a time. Don’t try to have one team work on multiple platforms at once. It’s a sure recipe for apps which don’t really succeed on either platform.
Reinvent The Wheel
Our app idea is new, and shiny! It is going to be the greatest, most-bestest app ever, and to make it so we’re going to dig in and get rid of all our assumptions — and all our old code. This will be great from the ground up, with all new routines optimized for doing the most basic things. Users will notice and love us.
This is the mirror-image of trying to reuse every last digit of your old code. This one is doubly bad. Not only will you waste valuable time when you reinvent every single wheel under your app, you’ll increase the chance of introducing bugs and errors when you choose not to use code that has already been vetted. The real lesson? Go into your repository and reuse code, but be smart about it. In this, as in so much, extremes are where you tend to run off the rails.
Think Of Mobile Apps As Miniature Web Pages
Everyone loves a good website, and we’re all used to the basic web interface. That’s why we’re going to build our app based on solid web page user interface standards. We won’t have to worry about building out the UI, and we might even be able to keep lots of the app in JavaScript. This is going to be great!
Except, it’s not. There are vast and important differences between the way users expect to interact with a website and the way they expect to interact with a mobile app. Don’t try to get away with doing a single UX design for both. Let each be optimally what it’s intended to be, and you’ll end up with happier users, a more productive workflow, and a more successful mobile app.
Be Really Fuzzy About Defining Success
“What will a successful app look like?” seems an almost absurd question, but you’d be surprised at how many dev efforts don’t really include an answer. In one sense, if you manage to shove the app out the door, then it’s successful. But we all know completing the coding for an app and creating a successful app are two distinct things.
The product owner is the one who should ideally develop the criteria for success. Criteria might include things like productivity gain, specific use levels, audience size, targeted cost reductions, and user satisfaction scores. Now, note all of these are business-case goals. That’s where the success really lies, and where designers and developers have to understand and agree on the definitions of success. Without such knowledge and agreement, you can easily get right back to the situation in which designers and developers are working on separate projects with the same name.
Be Your Own Beta Tester
Hey, you know what would prove our dedication to this project? We’ll “dogfood” it and be our own beta testers. That way, we’ll end up with a better app (after all, who knows it better than us?) and our example will show how great the app really is!
So, the idea of “dogfooding” (as in, we use our own apps, “eat our own dog food” in industry jargon) is powerful, but in this instance it’s powerfully wrong. The biggest reason it’s wrong is that you know the app too well. You know precisely what it’s supposed to do, so you’re less likely to try the truly bizarre things real beta testers will try to get your app to do.
Once it’s up and running, feel free to use it if it meets your business needs, but respect your eventual users enough to conduct a real beta test program with actual beta testers. For what it’s worth, your real users shouldn’t be your beta testers, either. They’re getting tired of playing the role with no warning and no reward. Just sayin’.
Forget Why You’re Developing The App
So here you are, deep in your 14th sprint of the project and boy, those new features are coming along nicely. This has become a great team-building project for the developers, and a lot of the code will be useful later on, so the project is a great success. The app will really help … which department was that again? Never mind, it will really help them do the, uh, thing it’s helping with.
We’re all familiar with development projects getting so big and convoluted the original purpose of the exercise is lost. Managers and project owners have to take responsibility for keeping everyone’s eyes focused on the reason for the app and the ultimate definition of success.
There they are, 10 ways to absolutely wreck a mobile app dev project — and 10 ways to keep things from running off the rails.