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
Waterfall Model
Iterative and Incremental Development
Iterative development was created as a response to inefficiencies and problems found in the waterfall model. Modified Waterfall, Rational Unified Process (RUP) and most, if not all, agile models are based on iterations.
General idea is to develop a system through iterations (repeated cycles) and incrementally (in small portions of time). Through them team members or stakeholders can learn from their mistakes and apply that knowledge on the next iteration.
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:
A typical waterfall project has well defined phases that go from the idea conception until putting the solution in production, being the most typical of them:
It’s very common in big companies that there’s a functional team responsible for each phase. Thus, we get:
However, one of the big problems from this approach is that usually these teams work in silos. The right hand doesn’t know what the left hand is doing and this causes inefficiencies. To make it worse, sometimes the way to try to reduce silos is through an immense increase in bureaucracy, forcing teams to communicate through documentation.
Continue reading
If you are still working in a waterfall methodology, you should know that the world is moving towards new methodologies… some famous concepts would be Agile, XP or Scrum and surely those words will sound familiar to you especially during the recent years.
Especially in the case of scrum, the first scrum team in which Jeff Sutherland participated took place in 1993, literally 20 years ago, and now it’s mature enough to be taken by big companies.
I tend to discuss things openly and often with my colleagues. Before I start Google-ing for some solution, before I start banging my head around some problem or before I start designing an application or some new feature, I tend to consult my coworkers and see whether their experiences might help. At other times, I see someone’s commit and became curious about the reasons for the way that someone implemented the solution or I might see the better way to do something. The list goes on and on… In all those cases, I prefer to get up, pair with someone and work it out. Ideally, that someone is sitting next to me. Those I communicate with do not seem to mind. Quite contrary. Unless they are very good at pretending, they act in a similar fashion and seem to do the same with me. All in all, there is a lot of communication going on, great ideas floating around and, ultimately, some kind of shared knowledge and ownership is established. I truly believe that those discussions are what makes us all better professionals.
Not every day is sunny in Barcelona.
Technology Conversations 