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.