Back to School: History of Software Development Methodologies

You probably know a lot about software development methodologies, and that’s great! How about systemizing your knowledge a little bit? Why did the world of software engineering need them to appear, how did they change in time and finally, how did they change the world? Read on for the answers.

Introduction

Let's put software methodologies aside for a while.

Imagine you’re buying an apartment. Only a decade ago the options in the market were very similar, and if it was something special, it was pricey.

But recently, developers have changed their approaches to housebuilding. Oftentimes, the apartments layouts within one floor differ significantly. This shift is due to the shift in housebuilding methodology - the floor plan is not known until the actual construction work starts.

Developers have become flexible. This allows meeting market requirements more efficiently.

Same thing happened to the software development industry. In time, legacy methodologies give way to the new approaches that are more flexible and meet the demands of time.

And here begins our story.

History of Software Development Methodologies. Beginning

Project management in the history of software engineering

Before the 1960s, when software development was in its infancy, no globally accepted software development methodologies actually existed. There was no need for that, when the term software engineering was barely known. However, the world already required project management along with people who were ready to manage large-scale projects that the 20th century saw in abundance.

Thus Gantt Chart appears in the 1910’s followed by Critical Path Method (1950’s), and 1970s saw Project Management Institute. Things have gone serious!

Age of sequential approach

Waterfall model (1970)

So, the time for great software development methodologies has finally come.

In 1970 the Waterfall model appears. Winston W. Royce, its creator, never actually gave the Waterfall model such a name, yet it stuck to it and since then no one seriously bothered themselves with coming up with something better.

Royce's brainchild was the first in a series of attempts to resolve the software crisis that broke out in the early 1980's. The reason for the software crisis was the evolution of computers and computer science, while software engineers didn't really know what to do with all that computing power and how to use it efficiently.

"The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! ...as long as there were no machines, programming was no problem at all... and now we have gigantic computers, programming has become an equally gigantic problem", Edsger Dijkstra said about the problem.

Back to Waterfall.

Although Royce himself believed that Waterfall should be iterative, advocated pilots and micro models, Waterfall was and continues to be wrongly considered as a sequential methodology. Yet even in such an imperfect state it more or less served its purpose.

Meanwhile, software technology was moving forward by leaps and bounds, and the 1980’s demanded more sophisticated software development approaches.

 Sashimi model (1980s)

In the 1980s, the Waterfall model receives much criticism. Computer scientists try hard to invent a model that would substitute Waterfall once and for all. Such was Peter DeGrace, who created the Sashimi model.

DeGrace did not introduce any revolutionary ideas, yet he tried to give the Waterfall methodology a little bit of flexibility. In the DeGrace’s model, all the neighbouring software development stages overlap each other. That means, during the actual coding stage, detailed design and testing were also performed. Nice try, Peter, but it fell slightly short of the mark.

If Waterfall was too rigid of a methodology, Sashimi was a too flaky one. No one knew what was exactly going on at a given point in time, project management became a mess.

Thankfully, one day Barry W. Boehm woke up and said: “I know what to do.”

Age of iterative approach 

Before we move on, there’s something we have to tell you about how and why the iterative and prototyping era started.

The time gap between the emergence of a new market demand and its implementation was to become minimal. Sequential software development didn’t allow that. That’s why developers decided to try something else to be able to deliver software projects fast.

Emergence of Prototyping

A useless fact: iterative methodologies appear earlier than object oriented software development. Object oriented programming became a new normal only in the late 1980's, while prototyping started spreading far earlier than that.

Now to the prototyping.

A huge impact on the wide acceptance of prototyping was made by legendary Fred Brooks, the author of "The Mythical Man-Month". Fred Brooks was among the first who mentioned iterative prototyping as a healthy alternative to sequential software development. In “No Silver Bullet – Essence and Accident in Software Engineering”, his another great piece, he specifically points to that:

That was 1987 and in 1988 the industry breathes a sigh of relief as it welcomes the spiral model.

Spiral model (1988)

“The waterfall model is dead. No, it isn’t, but it should be” - you can imagine Barry W. Boehm’s frustration with the Waterfall methodology. So, he worked hard to come up with a software development methodology that would substitute Waterfall once and for all.

By developing the Spiral methodology, Barry W. Boehm gave the start to iterative software engineering. His contribution is acclaimed by many software scientists, including Fred Brooks himself. As Brooks mentioned in one of his interviews: “I am an advocate for Barry Boehm’s spiral model, in which you do some feasibility analysis, you do some design, you do some requirements development, you iterate, and you test things on each iteration. You build prototypes as soon as you can.”

Spiral model was everything that Waterfall lacked - iterations, risk-based, a functioning product at the end of each iteration. Yet, it still inherited something good from Waterfall - the result of each iteration is strictly determined. So, the Spiral model allows for consistent system growth, transparency and high predictability due to repeatable risk assessment (find more on the methodology here).

What did Barry miss that didn’t let the Spiral methodology make it for long?

Agile (1990s-2000s)

A useless fact #2: did you know that Agile came long before Agile Manifesto was published in 2001? Yeah, that’s true. Have a look at the timeline.

1994 - Rational Unified Process

1995 - Scrum

1995 - Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM).

1996 - Crystal Clear, Extreme Programming.

See? Seems like someone pulled a trigger in the early 1990s and ph!.. they started popping up like mushrooms.

Seriously, Agile software development methodologies proved very efficient. As a contrast to its predecessors, Agile mindset is more about a product, not a software development project in the classical sense of the term.

Surely, few companies follow 100% Agile. However, small teams, working in increments, TDD and working software at the end of each iteration are certainly among people's favorites. A killer combo that helps significantly reduce time to market, which is everyone’s prime objective nowadays.

There are tons of articles written about Agile, not without a reason, obviously. Here we’ll focus only on the three most popular Agile methodologies, which are UPM, Scrum, and Kanban.

Unified Process Model (mid 1990’s)

Unified Process Model isn’t a typical methodology with clear milestones, lines and arrows. It is a little bit more complicated than that, which, possibly, didn’t make it so popular over the Internet. Nevertheless, it did manage to find its audience.

UPM has introduced a very important aspect to which many turned a blind eye over decades. The aspect of problem segmentation.

Problem segmentation means the time gap between the error occurrence and its detection is reduced to the max. The problem simply does not have a chance to grow big. Another great thing about UPM is user involvement, which also helps detect and liquidate system errors.

Scrum and Kanban

See a detailed explanation of how Scrum and Kanban work in our blog. Each article contains a great infographic for better comprehension. It’ll take minimum effort to understand and start applying these two great methodologies, so don’t miss a chance if you’re still on formal terms with Agile.

Software development methodologies - what's now?

You’ve reached the conclusion of this very long read. Thank you so much for coming so far with us!

As you know by now, software development methodologies vary a lot, come in different shapes, sizes and colors. They have been changing actively over decades to meet the demands of time. One can easily get lost when choosing the one that’ll suit best their software development project! As for us, we closely monitor Project Management Institute recommendations. Today it pays huge attention to the iterative and Agile approaches (see PMBOKⓇ Guide).

What else to say? Why Barry Boehm couldn’t kill the Waterfall model with his Spiral model and why Scrum isn’t everywhere? We should quote Fred Brooks for just one more time - there’s no silver bullet! Methodology and tools should be chosen according to the task, not any other way.

P.S.

Regardless of the tools, programming language and methodology, the success of the project lies is in the people delivering it. Great teams make great projects possible, not vice versa. Keep that in mind next time you’d like to try that buzz word methodology, framework, programming language, whatever. People. That’s our secret ingredient of success.

If you need more details on our methodologies (and people, of course), check our website or contact our Support team.