In the world of software development, it is not always easy for clients to make the right choices. There are many different methods, techniques, and philosophies used to deliver high-quality software. As a client, it's important to know what to look for and which approach best suits your needs.
This article provides an overview of the key aspects of software development, from Agile to DevOps and from CD/CI to version control. This will give you as a client a better understanding of the various methodologies and enable you to make the right choices for your project. Feel free to ask your developer for more information if it's not clear which method they typically use.
The waterfall method (large projects)
The waterfall method is a traditional approach to software development, where each phase of the project is strictly separated from the next. It is a sequential method, where each project is divided into well-defined phases beforehand, and each phase begins only after the previous one is fully completed. This method is somewhat dated and is most commonly used in extremely large projects, such as those of governments, where it is essential to monitor progress by definitively closing phases. Although this method is often criticized for its lack of flexibility, it can still be highly effective under the right circumstances, provided that proper preparation has been made.
The V-model (critical projects)
This method is similar to the waterfall method. The difference lies in the fact that testing is integrated into each phase of the development process to ensure the quality of the end product. The V-model is often used in critical systems, such as in aerospace and medical industries. While this method is so specialized that it is hardly used anywhere else, it is crucial for the safety and reliability of these systems. In the commercial sector, the DevOps philosophy is often used as an equivalent. We'll discuss this later.
The agile method (regular projects)
Agile is a pure method focused on planning and controlling software development, with an emphasis on iterative development of software in small steps called sprints. After each sprint, there is a review and, if necessary, adjustments, including pricing. Unlike the waterfall method, some sprints can run in parallel. This method is currently widely used as it makes the complexity of software development manageable for both clients and developers. Scrum and Kanban are variations of this method. The predecessor of the Agile method is the Incremental method, but it prioritized software without the collaboration and communication of the team around it.
The spiral method (risk-prone projects)
Similar to the Agile method, the spiral method is an iterative approach. However, this method focuses on managing risks in the development process. The project's development proceeds in cycles, where each cycle begins with identifying goals and risks for that cycle and for the entire project up to that point. Subsequently, a prototype is developed to test and verify these goals and risks. Based on the findings from the prototype phase, the development is adjusted and optimized. This method is particularly suitable for risk-prone projects with significant changes and a high level of uncertainty about the overall feasibility. It is also designed to minimize investment waste, even to the extent of "pulling the plug on the project" as early as necessary.
The lean philosophy (budget projects)
This is not a pure method but rather a philosophy that can be used alongside a method. It aims to minimize waste in processes, both in the business processes of the software writer and in the software development itself. The goal is to maximize the value of every euro from the client. This can be achieved by reducing complexity and considering what is truly essential, as well as by reducing unnecessary meetings and consultations. This philosophy is especially suitable for prototyping and minimum viable products, although it can be applied in any situation. It is the most direct path to results with minimal waste, though the outcome may be minimal as well.
The DevOps philosophy (modern projects)
Similar to the Lean philosophy, this is not a pure method but rather a hybrid of a method and philosophy. DevOps primarily focuses on automating the development, testing, and deployment of software, but it goes beyond that. It also aims to improve collaboration between development and operations to deliver high-quality software faster and more reliably. DevOps encompasses agile and lean principles, such as iterative development and continuous improvement. However, it also pays attention to the software and the entire environment, working with automation during development and delivery to achieve rapid and accurate results in any environment. We will discuss these environments more extensively later on.
Interlude: halfway to the finish Line
If you've made it this far, it's time for a sip of water. There are still a few terms to discuss, and then you'll have all the relevant information to set up your next project in the way that best suits your organization. Take a short break and come back to reach the finish line together.
SDLC: a structured guideline for efficient software development
Now, let's cover a few more terms, starting with SDLC. This stands for 'Software Development Life Cycle.' It is not a development method or philosophy but rather a framework for organizing a project. It provides a generic guideline consisting of six phases:
- Needs analysis (also known as 'inventory')
- Planning
- Architecture (also known as 'design')
- Development
- Testing
- Implementation (also known as 'deployment')
Following SDLC can help develop software more efficiently and in a more structured manner, thanks to clear guidelines for each stage of the development process. SDLC can be used in combination with different methods and philosophies and is scalable, from large waterfall steps and short Agile sprints to tiny DevOps iterations. However, the final step of SDLC is unique and can only be achieved with the DevOps philosophy. DevOps enables rolling out the tiniest steps, even smaller than an Agile sprint, including production environments. While the Agile method discusses the result of a sprint with the client, it still happens within a controlled environment. To explain this further, we must first discuss the various types of environments.
From development to production: a look into different software environments
- Development Environment
This can vary from a home workplace to an office workstation. It's the place where the software developer writes the code and first tests it to confirm that it performs as intended. - Integration Environment
This is often located in the office, but it can also be a server in a data center. It's the place where the work of one or more developers comes together and is merged through version control. - Testing Environment
If the merging in the previous environment is successful, the software receives a version number and enters this environment. Here, Quality Assurance (QA) staff work on checking whether the software functions as intended, has no unintended side effects, and whether there is no regression. - Staging Environment
This is the environment accessible to individuals other than the software company's personnel for the first time. Staging environments are often shared with the client and sometimes with other involved parties. It's crucial that a staging environment closely resembles the production environment to ensure the software behaves the same way in both environments. - Production Environment
This is the environment where the software will ultimately be available to all users. For instance, in the case of an online store, it's on the public internet, accessible to all consumers. For industrial software, it's the physical factory where the software will actually be used.
Returning to SDLC and the difference between Agile sprints and DevOps iterations: with Agile, the result is often reviewed and discussed with the client in the integration or testing environment. In contrast, with DevOps, the result is evaluated with the client in the staging environment and, after approval, can even be rolled out directly to the production environment. Due to the reliability of automation within DevOps, the sixth phase of SDLC can be implemented in both the staging and production environments. This is not advisable with the Agile method.
How SDLC and DevOps reinforce each other for reliable software development
DevOps is a popular approach in software development in recent years. Key terms within DevOps are Continuous Development (CD) and Continuous Integration (CI). These terms refer to automated steps taken within DevOps iterations, enabling the code to be quickly and reliably sent through all environments. Setting up a CD/CI pipeline requires some effort, but it ensures that each iteration can be rolled out in the same consistent way, even to the production environment.
For this reason, Exclusive-IT uses a DevOps SDLC as the standard approach, unless otherwise agreed upon with the client. There are legitimate reasons to deviate from it, such as lean for prototyping or assignments with a limited budget, and the V-method for 'mission-critical' projects with extremely high quality requirements. In such cases, DevOps SDLC may not be the best choice. However, in almost all other cases, it is the only robust approach for reliable and high-quality results.
The end of the under-the-surface look
It is fascinating to realize that what you have just read is only the tip of the iceberg when it comes to the world of software development. There is so much more to discover and learn, and it can sometimes seem overwhelming. However, with the right information and insights, you, as a client, can make well-informed decisions that align with your organization's objectives.
My hope is that this information has not only informed you but also inspired you to have confidence in making decisions for your next software project.