After watching this video, you will be able to recognize that software engineering is
different from civil engineering, describe how software engineering is constantly
changing, and describe how the project management model
does not work well for software development. A common practice that goes against working
DevOps is treating software engineering efforts as if they were civil engineering projects.
For a civil engineering project, you might want to build an office building.
You hire an architect who designs the building and creates a blueprint.
The blueprints are handed off to the construction team who follows the blueprints to build the
building.
Once that handoff is made, the architect moves on to the next project.
They may get consulted on some questions about the blueprint, but largely their job is done,
and they move on.
The construction team spends months building the building to the specifications laid out
in the blueprints.
When the construction is complete, the building is handed off to the maintenance team, who
then takes over maintenance of the building.
Unless you're in California, the ground doesn't move too much from under the building and
things are fairly steady from that point forward.
The problem is, we treat building software the same way.
Software development efforts are usually run as if they are civil engineering projects.
We view it as a project to be completed and then move on.
Architects throw designs over the wall to the developers, and they move on to the next
project.
Developers throw code over the wall to the testers.
When the project is complete, the whole thing gets tossed over the wall to the operations
team to run and maintain as part of a "business as usual" effort.
All the people on the project team get reallocated to new work and maybe a skeleton development
team is left for maintenance.
In contrast to this civil engineering approach, software engineering is organic.
The software stack under your application is constantly changing even when the application
doesn't.
The operating systems are being patched and packages are being updated because of newly discovered
vulnerabilities.
These changes affect the application, and the operations team has to deal with all these
changes on their own.
New features are constantly being added.
Once an office building is built, you usually don’t add new floors.
Software is not like this.
The behavior of the system is constantly changing.
Yet, we continue to treat software engineering as if it were a civil engineering project.
The project model is fundamentally flawed as a way of doing software development.
When a project is complete and people move on, there is no ownership.
This is not the way to create great software.
You want to treat software development like product development instead.
Products have long lives and continue to be enhanced.
If, instead of moving on, the same team builds and maintains the software, they will retain
a deep understanding of the code and feel ownership for the code.
They’ll have great ideas on how to make the code better.
We must stop treating software engineering like civil engineering projects.
In DevOps, we want stable, long-lasting team membership with end-to-end ownership.
This is how to create great software.
In this video, you learned that software development is often viewed as a project to be completed
and then passed on to operations to maintain.
Software engineering and the behavior of the system are constantly changing.
Team ownership and stable teams make software development more like product development
and less like project management.