DevOps Explained is a series of episodes that go through history and different aspects of DevOps.
Without understanding how we developed software in the past, it is close to impossible to understand the motivations behind starting the DevOps movement.
In this episode, we are exploring Waterfall and how we were developing software in the 20th century.
I am often asked by non-programmers to explain what I do and how I do it. Following is my answer.
I am a programmer and, like many others in my profession, I am a nerd.
“Wonderful thing with nerds: they’re enthusiasts. Not having a life means you get to love things with a passion and nobody bothers you about it.” – John Burnside
Many think that computers are really smart. They are not. They are as dumb as it can be. What they excel at is crunching numbers very quickly. They do not know how to think or reason. They do exactly what we tell them.
The job of a programmer is to translate real-world problems into numbers that computers can understand. A computer is like a child that will do everything you tell him to do. What you want him to do is irrelevant; the only thing that matters is what you tell him.
On rare occasions when my daughter does actually listen to me, our relation is similar to the one of a computer and a programmer. I’m trying to make her do something and she’s testing my patience by doing what I tell her to do instead of doing what I want her to do.
Continue reading
The waterfall model originated in manufacturing and construction where changes are costly and investment in design of the production line is often much less than potential loss if the actual production fails. It is based on idea that planning and design costs are much lower than those used in the actual production.
## Software development life-cycle (SDLC)
The software waterfall model often uses some variation of following phases:
When moving from the traditional waterfall process with manual testing towards BDD with automated execution of scenarios, one of the often asked questions is “how do you measure your test coverage?”. What it really wants to say is “we have high test coverage with manual testing, can you guarantee the same or more with the BDD?”. From there on usually comes the suggestion to transfer one-to-one manual tests to the BDD format. That’s not a good idea since the result would be less than adequate transformation to the different format without any tangible change. BDD is not only about automation but about the way we construct and deliver software.
Main usages of code coverage analysis is to:
This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.
The goal of software projects is to deliver value to stakeholders. Even though that might sound an obvious statement, it can be easily forgotten in traditional Waterfall projects. The very nature of the Waterfall process fosters the creation of different departments whose job is to receive work from the previous stage, produce something, and pass it on.
A simplified Waterfall model would be:
Each of these phases tends to have separate teams and departments. BAs work with requirements, architects write design documents, developers code, integration engineers integrate, testers test, and someone installs the software. Each of these departments is waiting for others to produce something, to start working on their artifacts and, once finished, to pass it on to someone else. The value for the stakeholders is, in many cases, unknown or forgotten. Most people involved in such projects are concerned about “doing their part” and throw it “over the wall” to those coming next. Moreover, artifacts produced by one team are often not used or understood by another.
Technology Conversations 