After 30 years of developing software I came to the conclusion years ago that in most cases, an Agile approach to development is superior.
The problems with SDLC are several fold. Most are based on deficiencies in the human element… Embarrassment of divulging lack of expertise, the vanity of believing one can know everything in advance, the belief that you can perfectly communicate technical matters in a written form and a few others.
It has been my long standing position that typically the people who say they are experts are usually not so. They come across as confident, and knowledgeable but often (not always), their knowledge is superficial. There ‘s a name for it and practical implications, sometimes devastating…
Here’s a link
Overconfidence Effect
The more humble ones are hesitant to make such grand proclamations of their expertise as they have and are often shown by the world that they are not experts and frequently run into situations for which they have no experience, perspective or solutions. The real experts know this always happens and hone their skills on getting out of the sticky situations they find. They are experts are troubleshooting, innovating, learning and evolving.
Back to SDLC
SDLC is based on the premise that everything that needs to be done is known in the beginning of a project. It suppresses the learning that occurs as a solution is developed and after problems are encountered. It leaves no room for learning about what you do not know and instead assumes you know everything at the start. That’s unrealistic, immature and naive.
I prefer to admit that I know only bits of what needs to be done and the process of development is not only coding, but learning about the underlying domain/process/application of the proposed software. After many years of consulting assignments, I know people always overlook the learning part of an assignment and just assume you will pick it up. It’s very big and important.
Frequently in my career, I have come to discover that in some ways, I know more than the Subject matter experts on whom I’m supposed to be relying. I’m not saying this to be egotistical, but often, looking closely at data and the guts of systems, or the business rules behind an application, one needs to learn details beyond what typical operational people need. Often the operational people have abstracted their knowledge into a higher level of understanding, and do not even remember the rules anymore. A perfectly normal occurrence. However, when ego gets in the way, they will put forth themselves as experts when in fact, they have forgotten many of the details. People hate to say they don’t know something or are unsure, so they white-lie about it and hope it will not be discovered.
Agile –
Agile assumes the journey involves discovery, learning, and determining what works best based on experience, not presumption. It allows for mid-stream correction and lets owners see it rather than imaging it. It makes the owner a huge stake holder in the outcome. It gives them hundreds of opportunities to steer the results and truly get what they want.
Where Agile fails:
All things are trade-offs.
With Agile, you risk less solid architecture, a more fractured design and lower performance, more security risks among others.
With SDLC, you risk missing the target completely, never delivering anything, scope creep destroying a project or schedule, ambiguity in requirements being misinterpreted, and relying on imagination for requirements.
Applications that are long-term infrastructure, need the highest performance possible, have strong security requirements, are unable to be fixed easily and others all require an SDLC approach.
Most everything else can be Agile.
My favorite model for SDLC-needed applications is to create an Agile version AS the requirements, then re-engineer it for SDLC development.