Choosing a Software Development Model: Predictability vs. Velocity

Making a decision has always been a challenging process if the stakes are high. Similarly, when a company has to decide on a software development model for their upcoming project, the business owner, the project manager, and the team members fear that they might lose a chance at huge success if they favor the wrong approach for the development process. Therefore in this blog, we are going to discuss the most popular software development models and how to choose the right software model that could fulfill all your project requirements. But before we dive into those details, let us look at what a software development model is and what options we have to choose from.

What is a Software Development Model and what are its options?

The set of procedures undertaken to build software is called a software development process. And how this process is executed is known as a software development model or approach. Every model has the balance of two factors namely predictability and velocity. These are the two types where one allows you to know what you are building and take it slower whereas another allows you to build it faster and embrace all the changes you face on the way. There isn’t anything like a one size fits all solution, there is just a right answer for a specific project. 

A predictability model is just like a puzzle where you first look at the complete picture on the box that you are trying to build and then start putting the piece together, even if you run into some complication, you have a picture to look onto to get the right guidance through it. A velocity puzzle is like building a lego miniature. You don’t completely know what you are building but you can improvise as the need arises and build a completely different product than the one that was suggested. These lego miniatures are built gradually and no one knows what shape or form they may take when you are done with them. 

The perfect example of the predictable approach is the lean waterfall methodology. The process here is to start a new stage only after the previous one ends. You must gather all the project requirements before you start developing the software. Developers have to come up with a solid plan to create a development that won’t change more often. Then it is followed by testing the entire software at a time and finally deploying the software. 

The waterfall methodology breaks the large projects into small chunks and follows the linear model for the development process. It can also include iterations and testing loops. But either way, you can’t start waterfall software development until you have gathered a large amount of information on the project. 

Scrum and kanban are examples of agile methodology for software development. These methods are focused on quick iterations and working in collaboration with the product owner to build the software as they desire. Here, you won’t know how a product might look when it’s finished, you just have to take care of all the business needs specified by the clients 

Pros and Cons of Predictability and Velocity

Every action has a reaction. Similarly, every choice has some consequences. If you know what they might be and how you can manage them, you can prepare for what’s to come. The predictable software development model enables you to see the consequences of the product even before starting your development project. You will already have the solutions and how to apply them when the problems arise. But in doing so, the speed of your project will be slowed because getting the complete picture of the project takes time. But it will be worth it as before even beginning the development of your product, you can completely optimize it making the development stage straightforward. 

On the other hand, velocity-based development approaches like agile methodology can provide you with a working functionality of the software as soon as possible. Here, you would not know the consequences, just the results that you wish to achieve. But the best thing? You can decide how to achieve them or how to make them work. 

Collaboration is the key in the models based on velocity. Even if any single party from the team of software developers and the product owner don’t cooperate then they would end up with a whole new mess of complexities in their product. Their product will be far from something they had wished for. The short period of planning and management is also prone to the risks of reworking software products. Your system can go completely out of order if you don’t keep a strong oversight of its design and architecture. Such messy systems have interdependencies and emergent properties which makes them difficult to manage. It is way less flexible and is more expensive than any simple application. 

Another drawback of using velocity-based development models is that it leads to uncertainty. The scope of work keeps changing so you won’t know what you are building until you have built it. Yes, you can develop and deploy the software faster than you might have using traditional approaches but you will be constantly making changes to it. Although the velocity-based models are good for rapid development and embracing change, every model needs some preceding design for system architecture. The predictability approach takes time but the chances of changes in the scope of work and functionalities of the product which cause headaches to the team are very less.  

There isn’t anything like the ideal approach to creating a software application. You have to gather knowledge about all the possible ways to build a software like predictability and velocity-based models and then weigh the pros and cons against your needs to decide which way can be the best option for you. 

The Software Development Model Decision Tree

I would not recommend any specific software development model to you. It’s the project requirements that should determine which approach can be the most beneficial for software development. There are a few things that you must consider before making that decision. 

1. Risk Tolerance

The first thing you need to consider about software is its risk tolerance. The risk tolerance of a company plays its part here but there may be more risks to the software divided into different pieces inside an organization if they malfunction. For example, an app for day trading would work as per the rules and regulations applicable to it. To ensure compliance, the team of software developers will optimize the design of the app using a predictable approach which would also mitigate the risk. 

Let us take another example where the malfunction of the application can seriously cause a life-threatening situation, i.e. a medical device app. Before such devices are made available for the public, they are properly inspected and tested to ensure the safety of the patient using the predictive approach. What I’m trying to say here is that each company in every industry must consider the cost of error in their app when they decide to build an app using a certain development methodology. 

Small businesses that want to offer complex apps or services should use the velocity-based model for development. They must specify their needs and build the services based on them carefully because sometimes a simple malfunction can also cause a massive financial impact on the company. So if you are focusing on or choosing a velocity approach in such cases, your development team can iterate to collect the feedback. This would help them further in delivering a satisfactory user experience. 

2. Budget 

Another most important factor you need to consider while choosing an approach for development is the budget of your project. How much money can your company afford to spend on creating software? The Predictive model is expensive in comparison to the velocity model. Also, breaking down the entire picture with every little detail can be very challenging before the initiation of the project. More efforts and costs mean if you want to use a predictable model then you need to have very deep pockets. 

If it is a short-term project then the velocity model would prove to be affordable. You can build the software in small iterations and gather the feedback of the clients to reiterate and improvise further. If money is the issue then velocity can help you. At the end of each sprint, you can get a usable part of the software which means that even if you don’t have it all, you can still work with even a little functionality present in the software.

There is a reason why I argue that the velocity approach is good for short-term projects. Velocity-based projects are known to go on and on for an indefinite time. If the work done in the sprint is poor then it would just increase their work as they have to improve them by reworking on the iteration until they get it right. In such cases, the team has to re-architect and sometimes even rebuild the software application. Such events can make your project expensive in the long term in comparison to predictable models. There is a lower cost per unit of value, but there is a higher cost spread over years of development.

To help you choose a specific development approach for your software project both budget and risk tolerance work together. when you are paying for your software project then it would be your budget and when you are paying to the insurance company, it would be your premium. Both things are the same here. You are paying premiums for predictable models to secure your future against the possible risks. But in reality, you are just dumping those risks on software development consultants. Meanwhile, velocity-based projects are fast indeed in providing desired results but they can’t be cheaper than predictive models in the short run. Collaboration is vital between the client and the consultant because the communication breakdowns would eventually lead to software breakdowns. 

3. Time 

Time is the third most important factor in the software development process. How quickly can you develop fully functional software and release it into the market? There are many market forces and other factors that can drive you to deliver the software product in the market as soon as possible. When you are doing it to beat your competition in the market then using the velocity model makes more sense. Apple is the best example of it. The company has always been the first to deliver to the market and then they focus on improvising their devices over time. If you can quickly render the first version of a working piece of software, collect the feedback, and improve on it, the agile models would thrive. It will enable you to create a strong customer base to gain the first mover’s advantage. 

When it’s not a race against time, you can follow a predictable model to deliver a complete working software product. You can also use as many checkpoints as you want along the way to make sure that the path you have taken is right. However, when you are using the predictable model, you also use the incremental build which enables you to create a functional prototype of the end product. So, you can now put aside all your worries about waiting a year to see the functional software which wouldn’t be able to perform up to your desires. 

You must carefully and thoroughly think overall about the three factors that we discussed here – risk tolerance, budget, and time while choosing the right development model for your software project. 

Your success depends on what you choose

Velocity and predictable, both models can add value to your software and development process. The technology industries always seem to hold onto the latest trends and try to fit all their projects into the mold that’s most popular in the town. But it doesn’t work that way, you must first see whether it is a prepper fit or not. I have told you this before and will tell you again that software development isn’t about doing it the right or the wrong way. Every way is the right way but the question is does that way suit your project? So before starting on with your upcoming project, weigh the pros and cons, look for the risk tolerance of the software, the budget constraints, and the requirements of the time to market. This would help you choose the way that suits your software development project.