What were the most used SDLCs before Agile?

Question

Before the creation of Agile, what were the most used models in Software Development?
I am writing a thesis on the various ITS software (like Jira) used to implement these models and I want to put a paragraph about the most used models before Agile and its derivatives.

Christophe · Answer 1 · 2019-08-25T21:09:08.457

6

If I understand your question, you're interested in SDLC that were before the emergence of the Agile, i.e. not only the agile manifesto 2001, but also the agile methods that were promoted individually by the authors of the manifesto (e.g. XP, Crystal, etc...).

SDLC time travelling

Before Agile, in late 90's, the most popular SDLC was probably the Unified Process, the first variant of which was the Rational Unified Process (RUP), designed by the founders of UML. It was already iterative and incremental.

Note that RuP was preceeded by the Booch method and OOSE in the early 90's. But these were quite new and not yet promoted by industry leaders.

Before, in the early 90's you had the Vee model or V-model and their variants. These SDLC were quite popular and were adopted by governmental agencies around the world, because they were meant to enable the construction of very large and complex systems, made of components (software, but even hardware or organisational measures), with emphasis on quality assurance and system integration. Note that in some agencies, nowadays Vee is still in force, but with variants that allow components to be developped using agile practices.

Another common SDLC in the late 80's was the so called spiral model. The idea was to have successive cycles of development to refine the software. But I would claim that this view was more academic, the development process of each cycle following the steps of the waterfall.

Before, in the 80's and before, the most common SDLC was the waterfall model with its mantra "Analyse, Design, Implement, Test" (to be understood: in strict sequence).

What is SDLC by the way ?

Note that SDLC means "Software Development LifeCycle". This describes the approach used to structure development projects and the successive stages of software.

SDLC is not about the practices or methods that are used:

For instance, both waterfall and v-model SDLC were used in conjunction with modelling methods like Yourdon, or Gane & Sarson, which were more related to the programming technologies (structured programming with strong separation of data and code) than to the SDLC.
Even in waterfall, some authors recommended the use of prototyping to validate the analysis and design before starting to code.
The Rapid Application Development for example used some interesting practices such as joint design workshops with the users and rapid prototyping to ensure short feedback loops. But these practices were embedded in a waterfall (or spiral) model.
There are some standards (e.g. software used in medical devices), which still impose a V-model, but standard specialists now read this as process requirements and not SDLC requirements).

edited Aug 25 '19 at 21:09

answered Aug 25 '19 at 16:21

Christophe

74,672
10
115
187

1

"the most popular SDLC was probably the Unified Process" - maybe popular among consultants to sell some hype to manager, but definitely not popular among people who really did practical software development. – Doc Brown Aug 25 '19 at 17:06
@DocBrown that's an easy remark full of prejudice. I would argue that it certainly depends on the domains in which you developed. As an argument, I would say that there are enough corporate variants of RUP nowadays that can be viewed as evidence of its real use. There is even Ambler's Scott "Agile Unified Process" that was build upon it, and I doubt that Ambler would have done this if UP wasn't use in practice... – Christophe Aug 25 '19 at 17:14
1

I've been doing software development for quite a long time, and have never had the occasion to work for anyone using RUP, nor have I ever heard anyone talk about it before (I've heard of RUP, but only in the context of corporate brochures). That doesn't necessarily mean that it is not popular, but it is rather telling. – Robert Harvey Aug 25 '19 at 23:10
@RobertHarvey with all due respect, your own experience is subjective and not a single source of truth. Personally, for example, I've never seen a project running true XP, but I would not dare to infer from my own experience a generality that would be untrue. And I've seen plenty of projects adopting some XP practices. I will not continue to argue, but just to show that I'm not the only one who witnessed the wide use of UP (or some variants): https://www.martinfowler.com/articles/newMethodology.html#rationalUnifiedProcess or https://ieeexplore.ieee.org/document/1517743 – Christophe Aug 26 '19 at 06:43
1

@Christophe, it's interesting that Fowler says: *"My experience with RUP is that its problem is its infinite variability."*. We could now comfortably say the same of Agile when seen in practice. – Steve Aug 26 '19 at 13:46
@Steve Indeed! Last year, Cockburn showed a slide with around 40 agile methods. For this reason, some authors interestingly suggest to move the focus from methods to practices. The idea is to let projects chose and combine the most appropriate practices, instead of creating yet another new variant of an existing method or starting method wars. This approach requires to package each practice in a reusable and independent fashion (i.e. a kind of SDLC patterns). It’s not mainstream yet and it’s difficult to predict the acceptance of this approach, but I like the idea. – Christophe Aug 26 '19 at 14:18
Was Waterfall *really* common in the 1980s? That is utterly scary, considering that Waterfall was invented as a *strawman* of a process that *cannot possibly* work. Why would anyone use a process that was *specifically designed to fail*? – Jörg W Mittag Aug 28 '19 at 21:50
@JörgWMittag Yes: it was not only common, it was the norm. Waterfall emerged already in the 50's. In those times, scientific management and Taylorism was still the dominant approach to organise work in large corporations (the only ones who could afford mainframes). And taylorism specialises job by tasks. End 60s and early 70s several authors proposed improvements, such as loopback, prototyping, and components. Believe it or not, a lot of projets succeeded in the 80s. – Christophe Aug 28 '19 at 22:20
@Christophe: That is truly depressing. Waterfall was invented by Royce as an example of a process that *looks* appealing to people who don't understand software engineering but that actually doesn't work. And he spends a good portion of the paper explaining *why* it doesn't work. Why would anyone choose to use a process that was created as an "*anti-process*"? – Jörg W Mittag Sep 02 '19 at 12:07
@JörgWMittag as you point out, Royce did not invent the waterfall (he was just the first to use the term) but tried to improve the process. There are older articles from the 50’s where pre-Royce waterfall was described. His improvements are a series of feedback loop that are very relevant in some contexts. Cliché’s will not make us better. There are some good things and some bad things in every approach. Keep in mind that we’ve sent people to the moon with software long before agile was around ;-) – Christophe Sep 02 '19 at 13:22

score 3 · Answer 2 · answered Aug 25 '19 at 10:39

3

Before the Manifesto for Agile Software Development, you had people using Scrum, DSDM, Extreme Programming, Lean Software Development, Adaptive Software Development, the Crystal methodologies, and more. Key people from several of these methods (before the Manifesto, they were calling them "lightweight" or "adaptive" methods) were meeting at different conferences and ultimately at Snowbird where the Manifesto was written. The Manifesto for Agile Software Development is an abstraction or an identification of common ground and common values and principles that capture why people felt that these methods were having success on various software-intensive projects that they were used on.

Before the Manifesto for Agile Software Development, you also had people who were trying to apply traditional project management techniques to software. But these techniques don't typically work well when applied to work that is not predictable and repeatable, which the bulk of software development is. It also doesn't take advantages of the economies of software development. Even though it's not a good fit, people attempted to use these techniques to apply discipline and control projects that were overrunning planned costs and schedules.

In short - not much has changed. However, there's a name and an entire industry of training, consulting, books, conferences and more built up around the name "Agile". That's new because of the Manifesto - it simply gave a name and built concepts around a bunch of otherwise disjoint work in improving the methods of software development.

answered Aug 25 '19 at 10:39

Thomas Owens

79,623
18
192
283

There is certainly a large industry built around "Agile", but there are more interpretations of it than practitioners. As you say, not much has changed. I think that too little work has been done on analysing the nature of the role of business software designers, and articulating why it is recalcitrant against reduction to a simple stepwise process with a fixed timescale and guaranteed results, and this is poorly understood even by the vast majority of practitioners. – Steve Aug 25 '19 at 14:12
@Steve: It doesn't take much analysis to know what works and what doesn't. All it takes is pragmatism, and a little bit of practice. – Robert Harvey Aug 25 '19 at 18:34
1

@RobertHarvey, I disagree, as far as software management goes, it has received a hell of a lot of analysis for decades and it's still almost impossible to describe exactly what works and what doesn't. Large software projects still routinely founder or overrun predicted costs and schedules. – Steve Aug 25 '19 at 19:16
@Steve: Exactly my point. No amount of analysis is going to make Waterfall work any better. – Robert Harvey Aug 25 '19 at 21:25
@RobertHarvey, that is probably true of all software development methods. But in my view the exact criteria by which a method is judged to be good or not, and the exact reasons why methods can't be made to work as well as many would wish them to, are not well understood. The ancient world knew they could not get alchemy to work, long before they fully grasped why, and until they did understand why, a significant amount of effort continued to be expended trying hopelessly, and charlatans also flourished. – Steve Aug 25 '19 at 22:17
Another way of putting it is that most businesses would prefer software development to be boiled down to a production line process, where large amounts of standard output arise on time by way of line operators (or machine tools and robots) slavishly executing a series of explicit (and often simple) instructions or operations. In actual fact, software development is more like the initial designing and engineering *of* such a production line, and it's not yet abundantly clear to commissioners or managers of IT projects why that initial design and development cannot itself be boiled down. – Steve Aug 25 '19 at 22:40
@Steve: *Results* rule the day. – Robert Harvey Aug 25 '19 at 23:07
@RobertHarvey, of course they do, but it is surely because *results often fall short* that interest has existed for decades in methodological analysis and the use of supposedly formal methods. Such methods are widely hyped, and almost everyone now claims to follow a specific method, yet we still see poor quality results and spectacular project failures (the very dangers these methods were supposed to address). – Steve Aug 26 '19 at 01:00
@Steve: Yes. That's precisely what I am saying. What I said in my very first comment. It's not like *nobody* has succeeded at this. – Robert Harvey Aug 26 '19 at 02:04
@RobertHarvey, but I suspect we're not in agreement, because *some* people can make consistent profits betting on horses too, and many more win *sometimes*, but neither software practitioners nor IT project commissioners like to think that what they are engaged in is such skilled betting by betting savants (or worse, unskilled betting by amateurs!). If it was all a matter of "pragmatism and practice", and if we actually understood *what that is (and what it is not)*, we would surely not keep seeing failures and poor quality. – Steve Aug 26 '19 at 12:43

score 3 · Answer 3 · answered Aug 25 '19 at 18:32

Like Christoph already explained SDLC is independent from a software development methodology which is still not what agile practices bring to the table. Agile is primarily process oriented. For the sake of the argument let's go with development processes.

The most popular method was, and to my estimate still is, none.

At most of the places I worked any adopted methodology has been an afterthought. And often they just pretended, picked some aspects that did not require them to change their ways and moved on. People were sent on a course, some half-hearted pledges were made and everything went back to normal.

It looks like this has changed to some degree over the last 10 years or so, Scrum is pretty ubiquitous today. Or at least that's what everyone wants you to believe, still a lot is window dressing. It is hip to be agile and you don't have to change much before you can claim you are applying agile practices. Most of the times it is just that: some agile practices in a given environment that did not fully embrace agile principles.

Most software businesses started out with a business person and a coder (sometimes one person) who just banged away, solving problems as they emerged. The coder just made what the business asked for. And often this "method" is hard to beat too.

This is indeed the reality, that most claimed "methods" in this industry (that is, to the extent practitioners claim that their de facto method follows some established industry practice) are just window dressing. To the extent a team do try to take a formal method seriously, the more they appear to slavishly spend significant amounts of working time engaged in practices without any real sense of what is thereby being achieved or how, or the more working time is spent fairly fruitlessly trying to establish what the supposed formal method actually requires them to do and why. — Steve, Aug 25 '19 at 19:42

What were the most used SDLCs before Agile?

3 Answers3

SDLC time travelling

What is SDLC by the way ?