Appszoom for Developers

3 obstacles that can hinder the app development process (and how to avoid them)

Posted by on 05/31/2016

5152854505_879cb6ca3d_b.jpg

The software development lifecycle is rife with unpleasant surprises for the unwary.

There are many things that can slow down the process – or stop it altogether – or take it into unwanted directions. Things like defects, project deadlocks, and energy spent on unneeded features can cause delays in the development cycle – affecting the quality of the product, increasing project risk, and delaying your app’s launch.

In this article, I will iterate some of these pitfalls and offer guidelines on how to avoid them.

software defects

Defects can range anywhere between simple glitches in the user interface, to bugs that cause the total lockdown of the app and the device, or features that do not function as expected. Defects are one of the most common issues you run into during and after the development of an app.

The problem is, if you don’t have a meticulous and well-planned approach at identifying and rectifying problems, you can end up with too many bugs and problems to fix – and you’ll be hard pressed to clear the stack of old bugs while new ones pile up. This can bring your development process to a halt and result into utter defeat even before you ship the app.

Bugs that pop up after you ship the app are even worse.

As most experienced programmers will tell you, there is no such thing as a bug-free app, but it is best to spot and address as many defects as possible before the app is released in app stores. There are many tricks that can help you achieve this during the development cycle. Here are a few:

  • Test early and often: Break your development cycle into smaller iterations, each with its own design, development and testing disciplines. This will help you break down the complexity and overwhelming amount of testing that is required if you want to push it at the end of the development cycle.
  • Use test cases: Define the use cases of your app, the goals and stories that will be accomplished. And for each iteration, specify which use cases and which scenarios of those use cases will be addressed, and which other use cases will be impacted by their development. This will help you identify the exact areas that will need to be tested in each iteration.
  • Break down complexity: Splitting your app into separate modules or objects with finite functionality will help reduce the effort required to test the app and open the way for advanced testing methods such as unit testing.

Cover every eventuality:  What to do BEFORE launching your mobile app


working on unnecessary features 

Otherwise known as overproduction, this happens when you produce more than is necessary to achieve the desired outcome, which effectively means you’re wasting your time on features that aren’t “must haves” and will not make a big difference to user experience and satisfaction.

Failing to identify and develop the necessary features early can have many unwanted results, including reduction of the test quality, delayed release, and important sections of the app being developed in later stages of development, when the development team is under a lot of pressure and is wont to make development mistakes.

I use a use-case-based approach to deal with this. Early in the inception of the app’s idea, I create a list of all use cases the app has to respond to and start separating them into A, B, C and D categories, A’s being extremely crucial and D’s being superficial and nice-to-haves. After eliminating the D’s (or putting them away for a future version or update), I start going through the A’s and B’s to see which ones can be pushed further down the stack, and I check the C’s to see if any of them can be D’ed. I go through this process several times with my analysis and design team to make sure that the A’s represent absolutely what is crucial for the app.

And then I start development by giving priority to A-level use cases and delaying others for further down the pipeline. This helps lead the development process in the correct manner, starting with what’s most fundamental and important to the app. It will also help you to get started on user-level testing earlier than when tackling requirements without a clear goal and roadmap.

It will depend on the scope of the project, but based on my experience, most app projects have only a handful of A use cases, and most apps reach an acceptable feature level when A’s and B’s have been completed and can get started on user tests.

delyaed deliveries on project artifacts 

Unfinished design documents, modules that haven’t been developed on time, glossaries that are due for weeks and months, etc.

App development is a very involved process: different teams and team members depend on each other’s work to carry out their jobs. Any delay can have magnified repercussions on other parts of the project and cause larger delays.

The iterative approach can help reduce delays in development. By breaking down the project into smaller chunks, you don’t have to wait for huge achievements before getting started on development. For instance, instead of creating a complete 100-page long use case document, the analysis team creates a brief 5-page description of the use cases selected for the first iteration, which can then be used by the design team to create the model that will be developed by the actual programmers. And it doesn’t matter if you have different teams for each role or are heroically taking them on all by yourself. Breaking down complexity can control delays and create tangible progress early.

over to you

I’ve presented three pitfalls that can bog down your app development process. I know there’s a lot more, but there’s only so much I can fit in a post!

I would be delighted to hear what challenges you face in the development cycle and how you deal with them. Please share your experience with us in the comments section.

Topics: Uncategorized