Mobile App Quality

Jan Olbrich
Mobile Quality
Published in
3 min readJul 31, 2017

The Start-Up Idea

Within the start-up scene originated some ideas suddenly every company had to apply to:

Be fast, fail fast!
Release a product as soon as possible, so we can get customer feedback!

All these are great ideas, if you consider what major companies did before. Releasing an application with way to many features every few months. This application had to do everything and if some part from the requirements list was missing, the release got delayed. By the way, the list contained 1474 or more requirements..

Thus releasing faster than the prior de-facto standard is a great idea. Unfortunately most of the time people ignore the big picture, resulting in a maintenance nightmare. I’ve seen MVCs (Massive View Controllers) with more than 8000 lines of Objective-C++ code. Adding a feature didn’t take days, it took weeks, even months and the development speed crawled to a stop. This is a result of technical debt, amassed due to focussing on releases and deadlines.

In conclusion, quality once again appeared in the eye of companies. They started to demand unreasonable rules (e.g. one of my prior companies put this rule in place “70% of new code needs to be unit-tested”). Having this logic defying rules, developers tend to rather ignore them and proceed as is. This doesn’t improve anything.

How do we change it?

On their quest to be better, developers crawl the internet. Better coders, better architects, better anything. Way to often they stumble upon posts about app architecture, programming patterns, new paradigms or other specific topics every super-/rockstar-ninja-programmer should know, but far too less they find something about quality. Yes it’s absolutely great knowing (and applying) the latest trends in development, but does it help you maintaining the app in a year or two? What happens after the initial development of an app? Who takes care of it? How do you release it? Which bug do you fix? And how on earth can you still develop new features while maintaining the app?

All these questions are not part of the normal focus of a developer, but still they ARE his every days life. The earlier you accept it, the better. And the better it’s for your company or customer, as you start to deliver higher quality.

Since you are reading this, you probably have the same problem as I did.. where to start?

This Blog

The idea of this blog is to answer the above questions and even more. As it is easier to follow a structured way, than just a few loosely coupled post, we will create an app and improve our idea of quality with every new post. This will lead us through different stages, requirements and ideas, which will all (hopefully) help you to cut less corners and maybe spend some more time on non-functional requirements.
If you are like me, you are sick and tired of writing demo apps. So there will be no direct code for the app. Instead we look at the specific requirements and steps to take to create the best, we’ve ever had. Since this app needs some practical relevance let’s collect some requirements.

It needs to:

  • Have a user interface (without one, what’s the use of an app?)
  • Request data from a backend
  • Parse data from a backend
  • Display data from a backend
  • Send data to the backend
  • Interact with the user
  • Be releasable without full manual regression tests
  • Be releasable within a short timeframe (in scrum we talk about new releases every 2 weeks, depending on the sprint cycle)

Oh and don’t forget:

  • A team (at least 2) is working on it

This is our list for now. Of course, if you have more requirements, drop a comment.

Let’s try to improve the quality of our mobile apps.

Next up: The developers Machine

--

--

Jan Olbrich
Mobile Quality

iOS developer focused on quality and continuous delivery