From Zero to Hero: The Story of the Native App Development at ImmobilienScout24 III

This is the last part of a three-part series of native app development @immobilienscout24 written by Iyad Tamer Agha, mobile engineer at Immobilienscout24. Feel free to read part 1 and part 2 to get more insights into the topic.

The non-technical measures

Technical methods and tools are essential for ensuring the quality of a mobile application, although certain non-technical measures can result in detecting software bugs much earlier or not occurring at all.

Pair programming: one of the practices that has become established within our team is known as pair programming, whereby two programmers work together in order to jointly undertake a programming task. The four-eyes principle results in more control over the written code and fewer errors. By working in pairs, the code is discussed in more detail, which leads to more reliable software. Collaborative working also means that knowledge is better shared within the team. Experience shows that another side-effect of pair programming is that colleagues working in tandem are less likely to be interrupted than colleagues who work alone.

Mob programming: an extended form of pair programming that is also used in our team is known as mob programming, whereby not just two developers work on a task, but the entire team works together on the code. This method has proved successful when the team wants to integrate a new feature into the app. It leads to consensus within the team regarding the jointly determined principles of the code for the feature.

Code review: another means of ensuring the quality of our codes is the code review. After a new feature has been implemented, the code is scrutinized by one or more developers from the team. The aim is to identify any programming errors and check whether the internal guidelines for writing code have been followed. This also encourages knowledge-sharing within the team.

The fruits of our labor

Just one year after the first release, our efforts paid off. We had 849,000 app downloads in the first year after release and this figure was 15 percent more than the previous year. Our App Store rating improved from 3 to 4 stars, reflecting increased user satisfaction. The team learned a great deal over the years. The key lessons were:

• Quality is not just a technical problem: practices such as pair programming and code reviews are just as important as technical measures for making lasting improvements to the quality of the software.
• The user is always right: if users decide which features the application should offer, the risk of offering something wrong is very low.
• Less is more: a good app is not one which includes every possible feature. It’s worth removing little-used functions and improving frequently used functions.
• Four-week release cycle: although the app was fit for release with new features after every two-week sprint, a period of four weeks proved to be best. This gives users enough time to evaluate the new features and the team has the opportunity to assess the success of the release and take appropriate action.

Our future direction

Most software-based firms started developing mobile apps with small teams. Over time, however, their use has become so widespread that for some products, most traffic is already generated from mobile applications — as is the case with ImmobilienScout24.

Due to the rapid growth of mobile applications, the model of a central team being responsible for mobile development is no longer sufficient. Our plan for the future is therefore to scale mobile development within our feature teams. We will divide our iOS app into separate software components (modules) so that different teams can develop their own app requirements independently of each other. We are expecting to reduce the time-to-market for the increasingly important mobile apps because speed is a crucial factor in setting ourselves apart from the competition.