Step One : The Technical Audit

One of the first decisions to be made when we’re looking at a legacy application is “Do we start again or do we evolve what we have?”.

Too many times we see too little thought given to this question as people already have preconceived notions about the best way to go. It’s a sad fact that the commercial model of many consultancies rely on large project fees from rebuilds. It’s also an easier approach from a development standpoint which means we often find we’re the only supplier advocating evolving the existing codebase. You can learn more about this question here.

One of the tools to help determine the approach is conducting a full technical audit. When doing this it’s important to consider two elements of the technical implementation:

1) The codebase & database/storage structure
2) The wider development environment and processes

The goal here is to identify a list of:

A) Issues and problems to be addressed; and
B) Opportunities to be implemented

to form a backlog of non-functional yet critical components of work. All too often the initial audit centres on functional requirements, gaps or bugs, which are important, but there’s no point implementing those changes without knowing that the technical foundations on which we are building are secure.

Codebase Audit

The nature of mobile application development, and the fact it is often an adjunct to the core product development, means that the codebase may have been built over multiple years, by multiple developers. The changing nature of the ecosystem means that frequently we need to reimplement or change functionality to meet evolving customer expectations, UI frameworks, new App Store guidelines and so forth.

When conducting a codebase audit, it is important to consider four key areas:

Technical Debt & Poor Feature Implementation
There is often a lot of technical debt within the codebase with features partially implemented or “hacked” in. It is paramount that an experienced developer looks through the applications code and understands where these areas are. Beyond that, a consideration for the underlying architecture is important to see if a more widespread refactor needs to be considered.

Security & Data Protection
Another area it is important to audit is the security and data protection approach presently by the app. As modern apps take on greater responsibilities in handling sensitive data it is important that data is stored and transferred in a secure and professional manner.

Particularly true for apps which are deployed internally within organisations which may contain more sensitive data than public facing solutions. Apps are also increasingly being used to store data when offline or when connectivity is limited, which again may mean a greater proportion of sensitive data is stored locally on the device versus other software implementations.

As part of this audit we also need to see if the coding standards and security provisions are in line with the wider protocols established within the company such as ISO 27001 and cyber security essentials and so forth. Often legacy & neglected code bases are forgotten about and fall foul of not being compliant with modern protocols and standards.

Library & Framework Updates
We also need to audit the versions of any supporting libraries, frameworks or other elements of the software stack. Modern applications are built upon a hierarchy of these libraries and staying on top of updating them is a core facet of application maintenance and security. Indeed if your app is deployed within either of the modern app stores your code base is likely to be audited and any out of date libraries will be flagged. This can cause inopportune delays when trying to hot fix an issue by having to update the application to update a library.

UI Framework
Fourthly the UI implementation ought to be audited. Mobile apps are unusual in that in the recent past the paradigms around UI implementation have evolved quite rapidly across both major platforms. This can lead to outdated or inflexible UI implementations which do not work well with modern devices. It is important to establish how the UI is implemented and whether this area needs to be updated moving forward.

Environmental Audit

The second area of auditing concerns the environmental aspects of the application. As modern app development has matured there has been an increasing number of development processes and platforms which can assist in the development and deployment of an application.

Staying on top of these processes and platforms is a challenging aspect of development but investing the time to bring these areas up to date or pay dividends in future development cycles. Primarily we look across four key areas of the development environment when auditing an application:

1. Platform Build Target
The first of these is the current build target for the application on the Android and iPhone platforms. The build target specifies the OS version that the application is being built against and in a manner similar to the library above it is easy to fall behind on this and end up targeting deprecated or unsupported OS versions. If the codebase has not been maintained this will preclude deployment into the app stores and again may inhibit the ability to release updates promptly in the future.

2. integrated development environment (IDE) Compatibility
The second environmental concern is around the IDE compatibility of the codebase. Again as the mobile landscape has evolved the development tools have evolved along with it and it is important that we are able to build the applications with modern development environments.

3. Automated Testing & Test Coverage
Thirdly we look at the presence of any automated testing that might give us coverage out of the box against functionality. Although unlikely to be in place with smaller projects, any applications which have been built with test-driven development in mind will need to audit the coverage of this development and or schedule some time to implement coverage moving forward.

4. CI & Tooling
Fourthly we look at any continuous integration or deployment tooling. Again a unique aspect of mobile application development is the deployment methodology wherein we need to allow our users and testers to receive signed versions of the application to test which involves additional steps and challenges versus more traditional web or software development.

How deployments are being handled. The speed of development cycle will be affected by the following points:

  • How deployments are being handled.
  • Where the certificates lie.
  • Who has access to the key store.
  • Which devices are provisioned.
  • The services used to distribute the builds.

Conclusion

Once we have audited both the code base and the environment in which the application is built we ought to be able to form a backlog of tasks and issues that need to be resolved. Clearly these issues ought to be prioritised and assessed for complexity, risk and time, forming a list of issues which can be included in future sprints alongside any output from the functionality audit in the following steps.

Continue to learn more about our springboard framework at step two below.