If I purchase an item from an online store and pick the express shipping option, the item will get to me in the shortest time possible, but I’ll have to pay more. However, if I pick the cheaper standard shipping option, the same item will be delivered but at a slower rate. This scenario reflects the beliefs of a popular project management mantra that states: “Good, fast, and cheap. Choose two.”
This popular belief originates from the project management triangle (also known as the QCS triangle, the iron triangle, or the project triangle). It suggests that the three primary contending components of a project — quality, speed, and cost — oppose each other so that only two can be optimized for any particular project.
All companies want to build mobile apps that are of good quality, cost-effective, and delivered quickly to keep up with innovation and competition. However, going by the implications of this popular belief, it would seem that this may not be feasible. It suggests that mobile developers will have to sacrifice one factor — quality, cost, or speed — in order to optimize the other two. So, for example, sacrifice app quality to deliver an app fast and at a lower cost.
But is this true? Is it the right thing to do? This article will look at all three factors and how they are interrelated, to show that mobile developers can in fact optimize all three factors by focusing on quality first.
An outright trade-off is not the solution
A closer examination of the project management triangle reveals that this belief is a misinterpretation. The triangle actually has speed, cost, and scope on its vertices, with quality filling the area (as shown below), demonstrating that changes in one constraint require changes in others to compensate, or quality would suffer.
As Rene T. Domingo, professor at the Asian Institute of Management, wrote in his paper: “[quality, cost, and speed] are like the three legs of a stool on which the customer would sit. A problem in at least one of them means there will be no product or no buyer. One cannot be sacrificed for the sake of the other two dimensions.”
What does this mean for mobile development teams?
As I previously mentioned, all companies want to deliver high-quality mobile apps, cost-effectively and fast to keep up with competition and innovation. But what do these mean? What do quality, cost, and speed mean for mobile development? Let’s find out.
Quality
The quality of an app is double-sided. At face value, quality is based on its fitness of purpose to the user, which refers to how a user perceives an app based on its usefulness or ability to help them solve a problem. For an app to effectively help users solve their problems, it has to be bug-free, have good UI/UX, be accessible, etc. These are all metrics that consumers use to gauge the quality of an app and can be considered external software quality indicators.
However, external quality is highly dependent on internal quality, which refers to the structure or architecture of the codebase. Internal quality metrics include, but are not limited to: clean code, component reuse, automated tests, proper documentation, and a reliable code integration and release strategy.
Speed
Speed refers to delivery pace. It refers to the rate at which mobile developers can deliver new features or bug updates that consumers need/want at the right time. A good bug fix delivered late is practically useless, as many consumers may have churned by then.
In mobile development and software development at large, the delivery pace is somewhat dependent on the internal quality of the codebase too. A poor-quality codebase can stall developers when trying to add code for new features into the existing codebase.
Cost
Cost in mobile development can mean a lot of things. In general, it is the totality of everything it costs to ship apps to consumers. It comes in two major forms: people and resources. The “people cost” refers to the cost of maintaining the mobile developers and every other person involved in building the apps. On the other hand, “the resources cost” is the cost of tools and utilities that aid development like compute, storage, memory, network, etc.
Just like speed, quality can also affect cost. There is another angle of cost called the cost of poor-quality software. It refers to those costs incurred by not meeting the customer’s quality expectations or having defects in the app. This cost includes internal failure costs (rework, retesting, redesigning/coding, scrap, downtime, etc.) and external costs (recalls, sales reductions, returns, customer churn, company reputation damage, company devaluation, lawsuits, etc.).
If internal quality is optimized, developers can ship reliable code quickly, thereby reducing wastage and cost of poor-quality software.
Finding a balance
It is clear that good-quality apps are non-negotiable to consumers, and the pandemic only amplified that. The phrase “there’s an app for that” has moved from just being a mere phrase to reality. More and more consumers depend on mobile apps to manage almost every aspect of their lives, socialize, make purchases, stay informed, and interact with others. Hence, new apps for literally anything springs up each day, making competition in the mobile app industry somewhat fierce. If consumers have an unpleasant experience with your app, and if you fail to fix it quickly, they move to the next competitor — a classic case of you snooze, you lose.
You can strike a balance between quality, cost, and speed if you focus on quality first — precisely internal quality. Among many other quality facilitators, this means that you prioritize good code architecture and invest in a reliable deployment pipeline using a mobile-focused CI/CD tool like Bitrise.
As you may already know, prioritizing good architecture means that you limit technical debt, document code properly, name variables properly, etc. This will make it easier for both new and existing developers to quickly figure out how the application works so they can add new code with more ease and lower the cost of future change.
The importance of a robust mobile CI/CD pipeline cannot be overemphasized as well. It ensures that you can catch bugs in the earliest stages before it gets out to your users. It also aids shorter release cycles as well as less time spent on testing.
As Michael Long, CEO of Merkely, once said: “Software with high internal quality is easy to change, easy to add new features, and easy to test. Software with low internal quality is hard to understand, difficult to change, and troublesome to extend”. Thus, quality begets speed which begets cost reduction in the long run.
Granted, there are times when the “focus on quality first” rule can be counterproductive, like when you’re building prototypes or proof-of-concept apps. In such cases, it’s OK to focus on spending as little as possible (both in terms of cost and time) to get as much as possible done.
Good and fast can be cost-effective, too
Focusing on internal quality might bring about an initial slowdown in development pace, but it makes it easier to deliver more rapidly and cost-effectively in the long run.
Bitrise believes in prioritizing optimization of quality and speed, and that’s why we recently launched the Gen2 Bitrise Build Infrastructure. As your project expands in size and complexity, so will the requirements for the build process — tons of tests, build steps and setup tasks. Long build processes can slow down development life cycles. On average, Gen2 has resulted in 50% faster build times and saved an average of 1,000 hours in build time per month for customers with large applications.
We did this so you and your team can continue to produce higher-quality applications without sacrificing delivery speed even as you scale.
Further Reading:
.jpg)
