Four development team practices for mobile enterprise applications
It’s time to get back to our series on better managing your mobile application projects. So far we have covered mobile application requirements and application design, so in this post I’d like to discuss application development.
Imagine that we are leading a team of 30 new mobile developers who are working on a large-scale mobile enterprise application. What can we do to ensure the quality of the application? Bingo! It would be best if we establish proper team practices from day one. I interviewed a number of mobile developers involved in current mobile projects, and here are some team practices that have benefited them the most.
Standardizing mobile development tools
There are a number of tools for mobile development available on the web, including tools for screen prototyping, integrated development environments (IDE) and version control. Team members from different backgrounds may favor different sets of tools. Some hardcode developers may prefer Notepad for coding, while the classic enterprise developers may use the Eclipse IDE.
It is essential to standardize the tools for the entire team by conducting a tool adoption workshop before development starts. It is also important to encourage members to adopt the agreed-upon tools for ongoing application development. Here are a few benefits of standardizing the tools.
- Standardizing tools like editors or IDEs can minimize issues caused by differences in default behaviors between them. It is not surprising when there are some encoding issues for a file created in one editor and reopened in a different editor; those issues are usually difficult to troubleshoot and time consuming to spot.
- Standardizing tools can also ensure that the created projects and files can be exchanged properly without additional convertors or third-party plug-ins. It is common for team members to exchange their configured workspaces or archives in order to share assets or reproduce testing issues, and this will be easier if the team has standardized tools.
- Modern tools also enable users to create operational scripts to automate routine and repeatable tasks. Those scripts can be developed and can evolve as team assets, and it will benefit the entire team over the long term if everyone is using the same set of tools to support them.
Code review process
It is always difficult to organize a full team of experienced mobile development experts. For a large development team, the code review process is exceptionally important to ensure the quality of work, especially when team members are equipped with different levels of skills and training. Given the general scale of mobile enterprise projects, automated code review processes play a significant role. The manual review process is used as a supplement to cover anything missed by automation.
- Automated code review: There are a number of popular tools such as Checkstyle and PMD that automatically review code against general coding guidelines and best practices. To provide a higher level of quality for some specific projects, the team may also want to introduce custom rules. I recommend that you schedule automated code review regularly so that any problems can be caught promptly and fixed before causing bigger issues.
- Manual code review: Though automated code review is in place, the manual code review process still plays a key role. There are a number of issues that can’t be screened by coding guidelines, such as the adoption of design patterns and broader application design implementation. I recommend arranging for senior mobile developers to be responsible for manual code review once a specific module is completed and to provide timely feedback to the module owner.
It is common to stub external dependencies such as web service calls during web development to enable parallel development of both client-side and server-side applications. The same idea can also be applied to hybrid mobile development, which consists of dependencies on Cordova plug-ins or mobile OS features. There are basically two parts of client-side development for hybrid mobile applications: HTML5 development and Cordova plug-in development. It is not uncommon that there will be two different teams of developers responsible for these areas, as they utilize different skill sets. I recommend that you stub the response across the HTML5 and Cordova layers, which will enable parallel development and will keep the teams’ concerns separate.
In iOS development projects with limited budgets, stubbing out dependencies can help from a project financial perspective. HTML5 developers can reduce their development dependency on the Mac OS, which is essential to build an iOS native package. The introduction of stubbing in an early stage of development also enables the early testing of continuous integration.
Continuous integration is not specific to mobile application development, but they are usually linked together due to the general expectation that mobile applications will have a quicker time to market. Continuous integration brings a number of benefits for mobile application development.
- Reducing integration risks: Continuous integration minimizes the risk of last-minute issues due to late integration. Integration issues are difficult to troubleshoot, especially when changes accumulate in a single integration. With continuous integration, integration occurs daily or even multiple times each day. Issues can therefore be spotted and fixed immediately before the changes accumulate.
- Creating workable deliverables regularly: With continuous integration, you can have test scripts in place to verify if the builds are workable. Instead of having a single build after a long development period, with continuous integration we can now create workable deliverables regularly. The project team and business users can freely select the target build for the candidates even if the latest build is not working due to unexpected issues. In this way, the team can retain a good time to market.