The True Cost of Change in Software Development: a Guide for Non-Technical Management Teams

Have you ever thought of how long does it take to change one text label in a mobile application? It is way too common request from a client of any outsourcing or product company, and working on over 35 projects simultaneously, we can receive around 10 similar inquiries per day. The reasons for such an update can be different — legal or compliance team requests, spelling mistakes, changes in business requirements, or usability improvements. From the clients’ point of view, the update is straightforward because it is just a change of copy. But with this article, I want to open a small door to the backstage for you and show “invisible” processes that stand behind such an update.

The introduction to change management in software development projects

Working closely with clients, we often hear questions about why some smaller changes can take much time, and today I’d like to share my wide experience and address key concerns over costs in the software product development life cycle. My article is intended for non-technical product managers and business owners who want to get to the meat of the problem and understand the software engineering process from top to bottom.

It’s critical for the non-technical staff to know the process due to several reasons:

• Better management of business expectations. Only if you understand the processes and timeframes, you’re able to facilitate the project planning.
• Effective risk management. There is no denying that the new product development process is complicated, but it is manageable. Any risk can be mitigated if you know software development frameworks.
• A clear understanding of cost. Every hour that your developer, devops, or quality assurance engineer spends on the task is tracked and added to the invoice. As you may know, the change of the copy in the mobile application will entail actions from different members of your remote development team, and, as a result, your software project time estimation will change.
• Smart cost planning. At Dashdevs, we use the following custom software development pricing models: fixed-cost and time and materials. A fixed-price contract is usually used if we know the project scope and can do a complete project cost estimation and budgeting. The time and materials contract is applied if we don’t have a finalized functionality specification or have never built products for this niche before, so we are not sure about the problems we may face. These software pricing models can be mixed, depending on the business requirements and selected product development strategy.

Accordingly, the main goal of this article is to explain to you the cost of updating an app, estimated in man-hours, and give you the ability to plan the releases realistically. I use a copy update for a mobile application as an example of the process since the difference between web and mobile app development processes is not significant.

The basics of custom software application development: the eradication of technical illiteracy

To stay on the same page with all the terminology, I want to add a few lines about the terms that are typically used in software development projects:

• Repository is a place where the codebase (source code) is saved. However, if developers always overwrite the codebase, it is impossible to manage the code or track the changes properly. That’s why it’s highly recommended to use the source code version control systems such as Atlassian BitBucket and Github. They keep track of all the code versions, names of developers who have made the changes, and the timestamps. Besides that, engineers can add specific tags for the branches or commits to simplifying the understanding of the branch business value.
• Git flow is a popular type of branching model for source code versioning system, created by Vincent Driessen. When team members decide to build features for the release, they create a new branch from the master. Later a developer needs to create feature branches to start the implementation, and as soon as the development of the functionality is completed, the code is merged back to the master branch.
• CI/CD processes are two tightly connected methods that bring a vast improvement to the entire system engineering process. CI stands for ‘Continuous Integration’ and includes all the activities that automate the release building processes. CD means ‘Continuous Delivery’ that is an extension of the CI process with automated deployment (after a branch merge, or by time) and automated software testing.
• User acceptance testing (UAT) is performed in the closing phase of the software testing process. It’s done by business stakeholders to verify the correct implementation of all the business requirements.
• Software regression testing is executed to make sure that the latest changes haven’t broken the existing functionality.
• The deprecated method implies the methods that become not crucial for the provider and are not supported for the future. In practice, developers receive notification that the new approach must replace the deprecated method.

What are the different types of software projects? — The Dashdevs classification

In this article, I’ll cover all cases that Dashdevs — a fintech consulting and software outsourcing company — has been challenged with over the years of its existence. We work with digital products and projects for companies of different sizes from POC/MVP solutions for startups to complex fintech products on a turnkey basis for reputed banks. If I try to group all our projects into categories to simplify the understanding of the article, the list will be as follows:

1. New project. This category means that we have never worked on the project before. Other mobile software development company (or companies) has developed the application, and the Dashdevs developers don’t know the structure or architecture and don’t have any documentation or information about the existing project. In most cases, we don’t have a setup CI/CD system or any other infrastructure.
2. Maintenance mode. This group includes software products that we’ve developed or fixed before. We have a basic (or full) understanding of the application, along with our documentation (or developers’ notes). Additionally, we may have an actual CI/CD devops pipeline and test environment.
3. Actual development. This section comprises projects that are under active development. In the vast majority of cases, Dashdevs teams don’t just write code, but they collaborate with the clients’ teams and assist them with the achievement of the primary business or product goals. As an example, on one of the projects, our teams are providing more functionality to the app, but the business customer needs to change a few lines in the greeting message of their live application.

There is little difference between these three types of development projects, while the main consequence for the business will be in the accuracy of the software cost estimation and predictability of the issues. Meanwhile, both parameters are correlated to our awareness of the project.

Framework for efficient software change management

On the surface, the task may seem perfectly simple, but it still implies some additional steps from the team and the so-called developer magic.

System investigation phase

This stage is mainly applied to the first category of software projects with the primary objective of understanding the project architecture and the relationship between the objects. To deliver maximum results, we analyze all environments and third party services. During the technical due diligence, we evaluate the entire system, all the integrations, and the code quality. Developers usually pull the codebase and try to run the project while we strive to build the application manually. It rarely happens that everything goes smoothly. Typically, we experience many headaches during the initial build processes that can be grouped into the following list:

• The codebase is not actual. It can be outdated or not completed since some source code hasn’t been pushed to the repository.
• The codebase is not enough. The code lines are not the only thing that is required to build an application. We usually need certificates that sign the build, certificates for push notifications, keys, and credentials to enable the use of third-party integrations.
• Empty or obsolete readme.txt file. This problem is caused by the previous developer-magician who doesn’t want to share the secret of a successful building process.
• Our IP is not whitelisted. It is a common security practice in the fintech and banking industry for the vendor or outsourcing service provider company to limit access to the API usage by IP. Sometimes we set up our own test environment, though in this case, everything may be fine from the coding side, but still, the application won’t work. However, as far as the app is new to us, we may spend some time investigating the reasons and communicating with the provider on getting access to the services.

It is worth noting that there can be one more category of issues since sometimes a mobile application is not something you need to work with if you want to update the copy in the app. The server side may transmit some texts as well. In this case, backend developers must do the primary development process, and they need to investigate the code on their side. From the product point of view, the backend update is better because most clients can see the refreshed text without the need to rebuild the entire application. However, looking further forward, such change implementation methods involve full regression testing.

The typical timeframe for the tech due diligence in software development is 24-48 hours, depending on the size of the projects.

Timely application upgrade processes

This activity is mainly applicable to the first and second types of projects. In most cases, the situation is as follows — the application was developed a while ago, and now different parts of it need to be updated. In fact, every 6-9 months service providers update something in their products, while that may include some breaking changes as well. Typically, they fix bugs, extend functionality, retire obsolete methods, and so one. We’ve also witnessed cases when a client’s application couldn’t have been compiled due to warnings and errors caused by the outdated components. We know from experience that too often, the update of separate components or integrations improves the overall performance of the application significantly.

Consequently, after the upgrade of the components and modules to the latest versions, we need to perform software regression testing. Sometimes after the update of third-party products, we need to change the request structure and then check if it doesn’t break anything in other parts of the application. In terms of figures, the average estimate for library upgrade may be up to 16 hours and up to 40 hours for a framework update.

The estimated time required for regression testing depends on the size and complexity of the product, as well as functional and non-functional requirements. Meanwhile, the values may increase if we don’t have any documentation and need to guess the correct behavior of the application. Hence, the numbers may start from 24 hours, but right after the actualization of the codebase.

Actual software application development

Previous stages are only a preparation for the real game and are actually only for new and maintenance projects. If the developer has the recent codebase and can build the application, they can start the required copy update process. The workflow contains the following actions:

• The developer pulls the code to the local environment and runs the project;
• They apply the requested changes to the text label keeping in mind different screen sizes, text wrapping, keyboard popup, and all the objects located on the screen. The most rational requirement from business owners is to make the text always visible on the app screen;
• The developer runs the device emulation locally using at least two different devices in the simulation. Typically engineers check on devices with a small screen and a large screen such as iPhone 5s and iPhone 11 Max;
• Since we use Git-flow on all the projects, the developer prepares the pull request and submits the changes for the code review. The latter is performed by the tech-lead or another developer on the project. The code review process helps to prevent human factor issues and improve the traceability of the changes across the team. In more complicated tasks, it helps to educate the team and improve the overall code quality on the project. At Dashdevs, code review is a must-have procedure on all the projects;
• A pull request is reviewed, and subsequently, it can be either approved or rejected. If the changes are approved, the branch is merged. Otherwise, the request is returned to the developer with an explanation. As soon as they fix all the comments, they need to resubmit it once again.

The estimate for this process ranges from 3 to 8 hours. However, there can be hidden dangers since, in mobile applications, one screen can be reused for multiple user flows, and the developer needs to check on his part that the code works correctly in all cases. However, we also have situations when a client wants to refresh the texts only for one of the use cases. As you may understand now from the business side, the task seems like a simple update of the text. But in a real-case scenario, the developer needs to redevelop the connection and the sequence of the screens.

Acceptance testing on real devices

We suggest testing all the applications on real devices, especially for the Android platform. Traditionally, clients provide a list of acceptance gadgets. We need this step because different device manufacturers have their own specifics of the Android interface. The quality assurance engineers must verify that the copy is appropriately updated properly in the correct user flow according to the business requirements, and the colors, font family, settings and sizes comply with the app design style guides. The estimate for this process is up to one hour per device. Usually, if we are talking about a small copy upgrade, it can be 15 min per gadget. Most of the time is spent on the installation and navigation processes to get to the necessary screen.

An end-user or client acceptance testing is a part of this step. We suggest the responsible person from the business side to verify the results too. We can share the build via TestFlight, Testfairy, or any other distribution system.

Submit app to app stores for review

After the client’s approval, we present the build to the relevant app stores for consideration. For instance, the Apple app store has a rigorous review process that can take up to five business days, but on average, it takes about two business days now. The Android Play has a much simpler reviewing process so that the application can be published in stores in 8 hours, and the enrollment process can take up to 8 hours too. The developer should have release notes from the business side. The timeframe for this step is — a few minutes to prepare the build, up to one hour to upload the build to the store, and one second to press a ‘Submit’ button. After review, the application can be either approved or rejected, and we’ve shared our best practices on how to avoid rejection in one of our previous articles.

As you can see, a small test update can imply a few weeks of development if the application is in a horrible state. Of course, we’ve described the worst-case scenario; however, have been facing them over the years. For example, an application was built by a few companies before us, and as an additional problem, we had no documentation or credentials. The first week was spent only on getting all the accesses from different vendors and companies.

Recommendations for non-technical and technical product managers

The process of custom mobile app development can be tricky because, in some way, writing code can be called art, and so software engineers are the artists. When you try to fix something, it’s important to have someone who can help you understand the logic and line of thinking of the previous creator. Meanwhile, I have a few pieces of advice for the product owners to help you perform your duties better:

1. Plan all the updates, including the worst cases. Be ready to manage risks associated with the lack of credentials or certificates, app store rejection, or implementation bugs.
2. Find time to set up CI/CD pipeline and eliminate the manual compilation process. The procedure of setup can take up to 8 hours, but it saves twice as much in the long run. Avoid manual processes in general if it is possible.
3. Don’t skip testing. The quality assurance engineers know their onions when it comes to various test cases that are typical for testing in software engineering, but you, as a product owner, don’t think of them.
4. Testing environments. Usually, we suggest having three different environments for development, testing, and production.

I hope this article helped you understand the development process better and answered some of the most urgent questions. Please let me know if you find articles like this one useful, and we’ll create a series sharing our hands-on examples and best practices. In your opinion, what are the friction points of a mobile app development process? What bottlenecks have you dealt with?