In his book – Software Development, Design, and Coding – John Dooley talks about the importance of choosing the right models for software development. He says that every software development project goes through a series of stages.
- Conception
- Requirement gathering, exploration, modelling
- Design
- Coding and debugging
- Testing
- Release
- Maintenance, evolution
- Retirement
Some development teams sometimes skip or combine one or more stages to quickly move ahead in the software lifecycle. However, there are two fundamental types of software development model choices. In the first type, the software development teams will go through a complete lifecycle before they move onto the next version of the software. The second type of development model, which is more prevalent now, the team will do a partial lifecycle, typically from stage 2 to stage 5, and iterate through the steps, come back, improve upon, and proceed for release.
These general types of software development lifecycles are easily implemented using two classes of project management models – the plan-driven model and the agile development model.
In a plan-driven model, the methodology is a bit stricter in terms of progression and release. Every stage is clearly defined and their requirements for sign-off on completion of a phase are on the higher side. Documentation is required at each stage after verification of completion.
When software development is undertaken for a large contract with well-defined deliverables, this is the perfect approach. On the other hand, agile development models focus on incremental improvements and assume that small and frequent changes and releases offer better scalability and production compared to larger, less frequent releases. The stages and phases in the agile development models are slightly blurred. There is less documentation of the work required, with the basic idea that code is what is being produced, and the developer should focus on that completely.
A great understanding of agile development can be found at Agile Manifesto.
In this article, we shall discuss different approaches to software development, their lifecycle models, both plan and agile driven, and compare them in detail to help you make the right decision.
The Four Variables of Software Development
Every project is different, and the approach to build the project depends on the immediate requirements based on the project domain, size, and experience of the team, and also the timeline.
Before we can get into the details of both the approaches, let’s understand the four variables every entrepreneur needs to keep in mind before starting with the software development. Whether you plan to do it yourself or hire someone to code it for you, these four variables are an immutable part of any software development plan.
The Four Variables are: Cost, Time, Quality, and Features.
Cost – You can’t spend your way to quality or being on schedule. You have a limited control over cost. The more you spend, the faster you can go to market. You can hire more programmers, designers, testers, and managers. You can offer the right tools to the developers and your teams. For small companies or startups, the cost variable highly influences the environment where the development happens.
Time – Time is your delivery schedule – when do you want to go to market with your software? What do you want your team to start using the software? For example, if we talk about consumer products, the delivery time is software between August and October so as to hit the holiday buying season. You can’t move Christmas. You will need to either drop a few features or compromise on the code quality. The Brook’s Law applies here – Adding programmers to a late project just makes it later. You need to hire the right programmers who can give you a realistic quote and timeline, who won’t leave you when you most need them.
Quality – How quickly and efficiently you can release the product, and how many deficiencies you are ready to release it with. You might make short term gains in delivery quality by sacrificing quality, but at what cost? It can take more time to fix the software before the next release, while your credibility shoots you in the foot.
Features – Every entrepreneur, founder, or developer should focus on features. From a customer’s perspective, features are the pillars of sales. The more features you deliver, the better your software will be in the eyes of the customer. Controlling scope of development allows you to control quality, time, and cost. But even more so, the developers should focus on controlling the features with each release. This is where estimates go wrong.
The Code and Fix Model
The first model we can think of is Code and Fix. It’s what most developers and freelancers do. It has nothing to do with project management per say. The model has no requirements, quality assurance, testing, or the release is uncertain. Hire a freelancer to build your project, and you might end up without any estimates or schedules. The delivery derailed and you will possibly fail at going to market.
It’s not completely wrong for a small project though. Let’s say you want to build a website with 10 pages. It’s too small to go with any presumptions. The developer will deploy a ready-made code and add some theme. The freelancer will make a few changes to the code here and there, and you’re good to go. There’s no maintenance involved, and mostly works well for tiny single-person programs and projects.
What is the Code and Fix Model actually useful for? With no real architecture or code review, little or no testing, no architecture and planning, the model is good for quick and bad looking prototypes and nothing else much. The code built using this model is mostly small, lacking any usable user-interface, and probably idiosyncratic. It’s great for testing and prototyping, but not good enough to be shown to the investors, and to the world.
The Waterfall Model
Created by Winston Royce in 1970 (looks like it’s aged already), the Waterfall Model addresses all the standard lifecycle stages of software development. It guides the development team from one stage to the next, from requirement gathering to architectural design, to detailed design, code, debugging, and testing. Again, detailed documentation is required at each stage, along with reviews, achieving of the documents, sign-offs at each stage completion. It’s an example of the plan-driven software development model. However, there are two fundamental problems.
- You are required to finish a stage before moving on to the next. You must complete all the requirements of a stage before the next stage work can be undertaken. You will have to complete a set of requirements, you’ll understand exactly what the customer wants, and everything the customer wants, before confidently moving on to the next stage.
But this rarely happens. You will rarely start working on a project where all the requirements are perfectly nailed down at the beginning. Things change as you progress during development. The necessity to finish one stage before another is a real world software development problem with the Waterfall Model.
- The second problem is that of assumptions. You never know everything you should know at the beginning of the project development. This is where the Waterfall model lacks in the software development process. Most organizations will eventually need to go back and start from scratch to resolve missed requirements, opportunities, or bad design decisions. Most organizations will have tweaked the waterfall model to help them not have to go through this problem repetitively.
In theory, it works well. It does isolate the different stages of the lifecycles and forces you to think about what really needs to be done before moving on to the next stage. It is a good model for inexperienced teams that are working on well-defined, new projects because it leads them through a lifecycle.
Iterative Models
“The best practice is to iterate and deliver incrementally, treating each iteration as a closed- end “mini-project,” including complete requirements, design, coding, integration, testing, and internal delivery. On the iteration deadline, deliver the (fully-tested, fully-integrated) system thus far to internal stakeholders. Solicit their feedback on that work, and fold that feedback into the plan for the next iteration.” – How Agile Project Succeed
While the Waterfall model is theoretically robust, it fails to recognize the requirement of foresight in software development. Mistakes in architecture design, user-experience, and code are hard to resolve once the product is shipped and in the hands of the customer. But an iterative process can help us resolve this. With an iterative software development model, we can foresee the problem that might occur and build products one piece at a time.
In most iterative models, you will have a partially clear idea about the requirements. You prioritize the requirements, primarily and possibly by taking customer’s priorities. This is the first time we will have the customer involved after the first stage of requirement gathering. You are practically tweaking the process for further iterations.
You will then have to pick the highest priority requirements and plan a series of changes and improvements, where each iteration will be a smaller project in its own sense. With each iteration, you will set a priority for customer’s requirements and build on it. By doing this continuously, by adding the customer and their requirements in the picture constantly, repetitively, you end up with a complete, working, and reliable product, that might not have all the features you thought of in the beginning, but enough to satisfy the customer partially.
These iterative processes follow a basic rule:
Your project, the whole project, has a binary deliverable. On the scheduled completion day, the project has either delivered a system that is accepted by the user, or it hasn’t. Everyone knows the result on that day. The object of building a project model is to divide the project into component pieces, each of which has this same characteristic: each activity must be defined by a deliverable with objective completion criteria. The deliverables are demonstrably done or not done.”
But eventually, there are deadlines to meet and deliverables to be handed over. What if something goes wrong during the project delivery date? What if the features are not enough? There will be only two possible solutions to this problem – either move the deadline or remove features. The iterative models need to evolve. Here’s how that is achieved:
Improving the Iterative Model
The iterative model follows what software developers call evolutionary prototyping. Priorities are set when requirements are received, and the software is developed with a succession of better versions of the product, possibly with better features. Each feature is based on customer feedback. When the requirements are changing, and often ambiguous, or the whole context of developing the application is poorly understood, this is a great model for development. However, eventually, we’ll have to move on to what was developed as the Agile Development model.
In evolutionary prototyping, there is a good understanding from the start – it’s hard to plan the complete project in advance, and feedback is a critical component of building something reliable.
This concept still needs improvement, but it’s not trash.
But then, the problems are right in front of you. Because of continuous feedback and iterations, the schedule and budget will be unrealistic. As the design evolves, there are high chances that the designed system will be crappy and it may only go bad, unless you start from scratch and build again – which is not always possible.
Evolutionary prototyping works best when you have an experienced team that has worked on several projects together. They know the ins and outs of the system and they can make iterations without losing on the context. Inexperienced development teams, freelancers, and teams using freelancers should avoid these models, because they quickly lose track of what to do next, and also what went bad during the previous iteration.
The Biggest Software Development Problem
Risk, the most basic problem that we tackle almost every day, is not new to software development. Schedules extend beyond limits, project cancellations, increased technical debt, misunderstanding in the business problem, or coding useless problems. Managing risk is a big time management problem and also a resource management one.
What we are looking for is minimization of the risk that we have to take when we start developing software with plan-driven models, with or without iterations. To minimize the risk, to build scalable software, to build on all these things without losing your mind in the middle of it all, is to build using Agile Methodologies which helps in controlling the four variables of software development efficiently.
With Agile Methodologies, the developers are in control of the four variables of development if they are capable of controlling the scope of the project. To give you a hint, Agile uses a metaphor – learning to drive.
It’s not about pointing the car in the right direction. It’s about the car, constantly being attentive to the road, and making constant improvements in the driving method to keep the car on the road. In the world of programming and software development, the only constant is change. If enough attention is paid to the changes, and enough action is taken to cope with the change, you can keep the cost manageable and deliver the software before the deadline.