Speed, Quality, Price: Choose Two When Building Custom Software

Written by
David Jackson

There’s an old adage that says of speed, quality, or price, you can only choose two. This mantra certainly applies when building custom software. For instance, you can develop software fast and cheap, but it won’t be of high quality. Or, you can build high-quality software quickly, but it will be expensive. Finally, you can build at a low cost and a high level of quality, but development will take a long time.

This is an inevitable trade-off, often called “the unattainable triangle”, forces you to decide which option to sacrifice. Let’s take a look at each more closely.

Option #1: Fast and Low Cost

Sometimes, a company may need a product quickly and have limited funds to spend on development. In this case, fast and cheap would be their only option. While it is possible to build software in this manner, the quality will suffer.

First, the rushed time frame and lack of resources will not leave enough time to properly invest in designing and testing the user interface and user experience. Instead of designing high fidelity mockups for each view of the application, building a clickable prototype, and performing user testing, you’ll likely have to settle for simple wireframes. This will result in a user interface that’s difficult to use and navigate.

Additionally, a rushed design phase will result in incomplete product specifications which will increase the risk of mistakes during development. A faster development pace will compound this effect and lead to more errors. In the end, your product will contain more bugs and deliver a poor user experience.

Since the dev team is building on a shoestring, there will be no time to implement error monitoring, user analytics, an automated test suite, and other development safeguards. Additionally, Quality Assurance will likely be rushed, which means more bugs will make it into production.

Best practices for UI and UX will likely also be cut, which means no loading states, buggy transitions, and sluggish load times, adding to user frustration.

Finally, the project will accumulate a lot of “technical debt” with complex functions, “spaghetti” code, and little documentation, making it hard to add more developers down the road. This is the very definition of low-quality code.

But, hey, you got in done on time and under budget!

Option #2: Fast and High Quality

If you’re flush with cash and in a rush to get the job done, you’re in luck. It is possible to build high-quality software quickly, but it’s expensive.

If you want to go fast, you need a large team of developers. But the more people on the project, the faster the team will burn through hours and budgets. Further, the more developers you add, the less efficient the team becomes (compared to a smaller team). This was illustrated in the classic book, The Mythical Man-Month by Fred Brooks, which eventually became known as Brooks’ Law:

“Adding manpower to a late software project makes it later.” - Brooks Law

Larger teams mean more people in meetings as well as more back and forth to keep the whole team on the same page. Additionally, more developers working on the same project means more time (extra hours) will need to be spent making sure all the code works together.

This large, expensive team that is working diligently on the app is going to need some serious oversight and coordination, which means more Project Managers, Business Analysts, and Quality Assurance Professionals.

In the end, you’re likely to have a sleek, professional, well-built app, but it will cost a pretty penny.

Option #3: High Quality and Low Cost

Surprisingly, it’s feasible to build high-quality software at a low cost, but there’s a catch: it won’t be delivered quickly.

The basic strategy for high quality and low cost is to eliminate as many professionals from the project as possible, and have one (or maybe two) highly capable senior developers do all of the work. A single person is much more efficient in terms of billable hours, and the small team size eliminates the Brooks’ Law dynamic (the Mythical Man-Month).

Smaller software development teams that consist of just one or two people greatly reduces the time spent in standups, sprint planning meetings, and internal communication. The total number of billable hours required to build the app will be far less than with a bigger team, but the total calendar time will be much longer.

Put another way, a 5-person dev team can build an app in 4 months. That same app will take 18 months with just one developer.

Conclusion

When you’re planning your software development project, consider what factors are most important to you: your budget, your schedule, or the quality of the finished product. Then, choose two and start building your development team.