DevOps Explained is a series of episodes that go through history and different aspects of DevOps.
Agile changed the way the software industry operates. Was that enough?
In this episode, we are exploring Agile and how it changed the software industry.
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
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 