The Disadvantages Of The Software Development Life Cycle Or Why SDLC Is Considered Harmful

Alex Borodin

Many experts consider the software development life cycle (SDLC) methodology harmful. But why is this? What are the disadvantages of using the SDLC methodology? In this blog post, we will discuss these disadvantages and see why SDLC might not be the best choice for your next project.

# Tech
August 27, 2022

Free code review checklist and best practices

Download

The software development lifecycle, sometimes known as the SDLC, is perhaps the most frequent misconception about software development. You may find something like this if you Google the phrase: "according to ISO/IEC/IEEE 12207 typical Software Development Life Cycle, there are the following stages: Requirements, Design, Develop, Test, and Release."

There are also two images of Waterfall SDLC, with the sages in one row, and the Agile software development life cycle, where the stages are in a loop.

waterfall vs agile sdlc

Isn't it true that software should be designed in this manner? But it isn't. It's not about steps; it's about processes. We should plan continuously, build continuously, and test continually from the very beginning. It's not a line; the processes are proceeding in parallel. Even ISO/IEC/IEEE 12207, primarily intended for public procurement, does not mention stages.

A staged process is a Waterfall; a cycled staged process is not Agile SDLC; it's a series of mini-Waterfalls. It is ancient, out of date, and does not function effectively.

Only 11% of Waterfall projects are deemed successful by CHAOS Report 2015. In their work "Life Cycle Concept Considered Harmful," published in 1982, Daniel D. McCracken and Michael A. Jackson wrote: "An increasing awareness that systems requirements cannot ever be stated fully in advance, not even in principle, because the user doesn't know them in advance-not even in principle.

To assert otherwise is to ignore that the development process changes the user's perceptions of what is possible, increases his or her insights into the application's environment, and often changes that environment itself. We suggest an analogy with the Heisenberg Uncertainty Principle: any system development activity inevitably Changes the environment out of which the need for the system arose. Therefore, system development methodology must consider that the user, and their needs and environment, change during the process.

Advantages And Disadvantages Of SDLC: Focusing On Requirements Gathering Phase

Today is 2022. Imagine the expense of software delivery failures throughout 40 years! Please don't go into details about the requirements before you start working on them. Don't have an "I need to think everything over" attitude. Instead, begin with small but essential items and work your way up. It is the only method to save time and budget.

SDLC Problems In QA Testing Phase

The SDLC misconception affects not just the requirements process. The second victim of the software development process being implemented incorrectly is QA. Testing isn't a step following development.

Imagine a chef with a runny nose who cooks with his eyes shut. And a waiter that smells and tastes the dish before bringing it to the client. That's how a test on the end looks. So what happens if the meal is terrible? Typically, we term it a "missed deadline."

Imagine a tester with a $70,000 annual salary who spends one day manually checking to see if a developer with a $70,000 yearly wage failed his assignment. If the task is unsuccessful, the developer will work for one week to repair it. It will set you back around $2,000 and a week of effort to fix. That is the cost of testing at the end.

In "The Mythical Man-Month," Fred Brooks suggests that development accounts for 1/6 of the entire project time, with testing and fixing accounting for another 1/2. It was 1973, and they utilized Waterfall and the "test after" method.

Also, why should a tester who just clicks the mouse all day be paid the same as a developer? The testers should not spend all of their time clicking. It's ineffective and painful, in addition to being unethical. What if QA creates a list of predetermined criteria that must be satisfied before a task can be confirmed as ready? What if these criteria will be carried out automatically during the checks?

In this situation, testers operate to prevent bugs rather than find them. They don't perform the final test; everyone always does it. QA gains time by eliminating rework efforts, which saves personnel hours. The system has living documentation that is updated as the project progresses. The system also has self-checking documentation, ensuring it functions as intended.

What's the cherry on top? First, there is no "we don't have time to automate tests" problem. The tests are already automated to assess job readiness. A company should not constantly choose between lowering the time and cost of manual testing and adding new essential features. The quality is built-in, which is impossible if testing occurs after development.

There are many names for these techniques - TDD, BDD, ATDD, and Specification by Example, but they all "breach" the typical understanding of software life cycle models. Testing is not a phase after development.

TDD Aproach

Problems With SDLC Process: Inaccurate Initial Budget Calculation

Why do companies continue to use the SDLC approach when we've known for almost half a century that it's incorrect? First, of course, it's due to budget constraints. How much money is required to create whatever they want?

What is the most straightforward approach for a software development firm's salesperson to earn the bonus and close the sale? That's correct. State the price. The consequences will not occur immediately but instead in the future.

But how can we know the price if we don't know, even, in theory, all the requirements? Because the incorrect project price becomes the primary determining factor, the sales process devolves into guessing, if not lying, rivalry. This explains why only 11% of Waterfall projects are successful.

Another approach to budget software development is to look at it from a different perspective. Every executive knows a company's MRR and the proportion of that revenue that may be spent on certain things. Typically, software development is not a one-time expenditure; it's a series of monthly payments. We live in a world where such a model reigns, and we budget office costs without knowing how many people will visit it and pay for internet usage without knowing how many gigabytes will be downloaded. As a result, we budget for development without a clear picture of what we'll make.

Businesses are well-versed in their monthly financial constraints; software developers, on the other hand, charge by the hour. So choose those who enjoy working together and have industry expertise based on your budget.

Wrong Cost Estimate In Software Development Cycle

What if it's the incorrect option? Delivery is also a continuous process, so if the program is delivered in tiny but valuable pieces, the company will be aware of the wrong choice as soon as possible. The risk of receiving a smaller value than anticipated is nothing compared to the danger of failing entirely in completing the project after months of development due to the wrong estimate.

delivery-sdlc

Do upfront estimates help to minimize the risks of software development projects? Do they guarantee that the job will be finished on time and within the budget?

According to Steve McConnell's book "Software Estimation: Demystifying the Black Art," which is perhaps a bible of estimation, the uncertainty on the stage after requirements are finished is 2.25 times. It is the lowest level of uncertainty - when the estimate is made correctly, and project management can make decisions and manage scope and resources.

In reality, when a budget is established, there are generally no specified requirements, and the project manager has little control over the scope and can't hire top developers. In addition, of course, the scope will vary due to changes in your business. So what is the worth of such an estimate?

That is why, in most cases, Waterfall projects fail. The company that can effectively lie to the customer wins the contract. Even if you're telling the truth and it's all very real, no one would take "from $10k to $500k" seriously.

Another issue is an underestimation. Senior developers are more aware of pitfalls and consider additional factors than less experienced individuals. Junior employees overlook many routine tasks that should be completed.

Consider a client who has received ten bids from prospective vendors in the range of $10k to $500k. What would you do if you were in the shoes of any reasonable person? Naturally, you'd pick the one with the "reasonable price." But unfortunately, it also implies less skilled developers with worse estimating abilities.

But what if a developer not only gives an estimate but also commits to a fixed-price project? Is it possible for consumers to avoid any financial setbacks as a result of an incorrect guess? Unfortunately, that is not the case. If the project isn't completed on time, there's no way to get it done ahead of schedule. The deadline will be missed. Being late has the potential to result in far more significant losses than planned expenditures. Not to mention, the Death March needs a sacrifice, and it is quality.

Overcoming Problems With SDLC Process: What Can You Do To Lower Your Risks?

What is the remedy? What can really lower your risks? A recurring monthly budget, small iterations, rapid feedback, and no fear of modifying scope at any moment.

How do I deliver my product by the desired date? How can I make sure I don't miss the deadline? It's also possible that the date cannot be changed for legitimate business reasons. Exhibitions, conferences, and holidays like Black Friday are examples of when it may not be feasible to move the date. Some legal changes necessitate a building deadline.

Yes, indeed, we don't know how long it will take because we can't define the whole scope ahead of time. We don't know how long it will take, but we need software to date. Does it appear to be a mission impossible? Shouldn't we go back to "traditional SDLC," even if it isn't effective?

Unfortunately, the illusion of control will not deliver actual control. What if the plan goes wrong in some way? What would happen if the plan is incorrect in any manner? It's more than likely to be incorrect. The team will have to work overtime to complete the project, which will be stressful and time-consuming. Code and architecture chaos would result from exhaustion, while slowing down is unavoidable. It's a Death March. As Robert C. Martin puts it, the only way to go fast is to go well.

Remove the waste instead. Create something small that can fulfill the most basic requirements. Do it as soon as possible, iterate, improve, and add new capabilities as often as possible before the deadline. Then, at each point in time, have functional software.

deadline comes close

Do you need to show off something at an exhibition? A simple UI prototype will likely perform worse than a complex web application and perhaps attract fewer consumers, but it will work. A rich web application that is not yet finished will not. Even for new legal requirements that are all required, there is a chance to mitigate risks because not every consequence is the same. Work your way up from the worst-case scenario and then iterate to cover the rest.

You have no risk of failure when ready-to-use software is completed well ahead of the deadline. All additional features and enhancements will help you succeed and strengthen the competitive environment. In addition, you can skip over any unfinished elements on the date because most essential components of the software have already been created.

Wrap-Up: SDLC Models Advantages And Disadvantages

As any project manager knows, the software development life cycle (SDLC) can be a complex and time-consuming process. Managing multiple team members, coordinating different project stages, and ensuring quality assurance can all be daunting tasks.

However, there are a number of ways to overcome problems with the SDLC process and ensure a successful outcome. One way is to establish a recurring monthly budget. This will allow you to track costs and ensure that they stay within the project's scope. Small iterations can also help improve communication and coordination between team members. Rapid feedback can also be used to identify and solve problems quickly. Finally, don't be afraid to modify the project scope at any moment. By being flexible and adaptable, you can overcome any obstacle that comes your way.

Author
Alex BorodinChief Operating Officer

Related articles

Free code review checklist and best practices

Download

Full-Service Software Development Company. We specialize in Ruby on Rails web applications, headless commerce platforms, and bespoke eCommerce product development.