This blog post is the fifth in a series, describing how app development works in a typical client-agency arrangement. The intended reader for these posts is someone who is looking to get an app made, who wants to know how the process works. This series covers how you might work with an agency to build an app and incorporates some of our learnings from our previous projects on what tends to work best.
Finally, on to the actual development of your app! Development is the longest part of the process, involving ‘coding’ or programming the app itself, and it’s also the most difficult to budget time for as there are a lot of factors that can affect it.
The Process
Development is typically structured around a particular project management model. As app projects can be very different in size and scope, there is no one method that works best for all projects.
For many projects, an agile methodology is used. There are several varying agile methodologies, but they typically involve an iterative cycle of designing and developing a few features at a time. At the end of a cycle, those features should be tested and ready to release – even if just to the client. Continuous feedback and refinement are important parts of an agile process. Agile project management is particularly useful in large app projects for a few reasons. Firstly, by developing in short cycles and releasing a usable app frequently, issues and bugs can be caught early. Secondly, for the same reason, it enables the discovery of improvements or additional features at a point when it’s much easier to be flexible, rather than at the conclusion of all development when many more technical decisions have already been made.
On some projects, especially small projects, a ‘waterfall’ methodology is used. The waterfall method is essentially following the software development process in a sequential way, such as:
- Design
- Implementation
- Testing
- Deployment
This can be very efficient if the scope is set in stone, but it leaves you unable to easily adjust course to change features, which is why it can be tricky on larger projects where changes come at a higher cost.
There are many other methodologies that don’t fit into agile and waterfall. Typically, they exhibit some characteristics of either iterative or sequential development and are intended for different use cases.
Some things to note
Estimating is Difficult
The single biggest issue with software development projects is that estimating how long features will take to implement is very difficult. This is a widely accepted issue throughout the software development industry, and there are few solutions to it, other than to allow a reasonable margin of error in estimations.
Across a whole project of features, misestimations can even themselves out – the overruns when developing one feature are cancelled out by another feature taking a shorter amount of time than expected. For this reason, estimating is generally less accurate on a small scale than a large one;
It’s hard to rush things
Software development can be uniquely difficult to ‘scale up’ and complete more quickly. It’s a well-known issue in the industry that many development tasks can’t be sped up simply by putting more manpower on them. In fact, there’s a term for this – the ‘Mythical Man Month’, often jokingly summed up by ‘What one developer can do in 1 month, 2 developers can do in 2 months’.
Because of the difficulties in scaling up the resources on a project, it can often be a difficult balance between trying to develop in the most cost-effective way, versus trying to develop in the most time-effective way.
Testing
Testing is a vital part of the development process in any project, but the way it is done can vary a lot. Broadly speaking there are two main kinds of testing: Manual Testing, and Automated Testing. Manual testing is done by a person manually using software, while automated testing is set up to be able to run automatically.
Manual testing requires lower set-up costs, but is expensive to run at a large scale, as it takes a lot of time, and time increases the cost of a project. Automated testing on the other hand involves high setup costs, as tests are written, but is then cheaper to run regularly. Automated testing becomes vital as projects grow, as retesting old functionality to make sure it still works after changes could get very expensive on larger projects.
Test Driven Development
Many developers follow a method called Test Driven Development when writing code. This entails writing automated tests for their code upfront before they even write the code – they then know that the code is working once the tests are passing. This method can be very useful for ensuring the code does everything it needs to but can unnecessarily increase costs in use cases where it is not necessary.
Acceptance Tests
The minimum level of testing required from a project is acceptance testing. Acceptance testing is the process of testing, whether manually or automatically, that what has been developed meets the acceptance criteria of the requirement User Story you are implementing.
Testing is important, but it is also an expensive process, that needs to be balanced with the budget and the other requirements of the app.
Payment Structures
Development can be expensive, and whether a project is paid upfront or afterwards could cause either the agency or the client to be taking on a lot of risk. For this reason, many different payment methods are employed by agencies doing development work.
One common structure is to charge a deposit upfront, with the balance upon completion of the project. In larger projects, this structure would involve setting milestones for development upon which work is billed for, which is sometimes necessary to provide appropriate cashflow to the agency doing the development if a project takes several months.
In some agile projects, especially those where design and requirements gathering is an ongoing process, payment is made per sprint, rather than per feature. Under these arrangements, User Stories are created, estimated, and completed sprint by sprint, but there is no clear idea of what the total costs or features will be at the outset. These arrangements would involve some kind of notice period to terminate the arrangement by either party.
Delivery
Software projects rarely have a point where they are suddenly finished, and typically apps have ongoing releases with new features and bug fixes for the duration of the time they are available to users. At some point, however, the arrangement for an agency to build you an app, and the agreements you have signed will be completed.
In the ideal world, an app would be able to be delivered in a completely bug-free state. Unfortunately, this is simply an impossible task, and there will always be issues (albeit not always major ones) that only present after the project concludes. In our next post, I’ll discuss some of the ways the app development process is handled post-release.
