Is DevOps & Full‑Stack Hype Killing Developers? A Critical Analysis

Introduction

Full‑stack engineers (referred to as “full‑stack” developers) and DevOps are undeniably the hottest terms today, both abroad and in China, far exceeding expectations.

Are full‑stack and DevOps merely new career directions, or are they simply the darlings of startup founders? This article offers a rational perspective.

At the end, nine foreign companies that excel at DevOps are listed.

Main Content

Two especially annoying trends have emerged: the ideas behind DevOps and the “full‑stack” developer.

DevOps has become so popular that disliking it feels like disliking the x86 architecture or a single‑core CPU. What caused this phenomenon, and why does it cause such pain?

Not every company is a startup, yet many feel compelled to act like one.

DevOps aims to foster close collaboration among development, operations, and QA roles.

Because software release frequency is increasing, the traditional waterfall development‑test‑release cycle can no longer meet business needs, forcing developers to also be responsible for testing and environment quality.

As developers’ responsibilities expand, the demand for an all‑round “full‑stack” developer arises.

This means a developer must also act as a QA team member, business analyst, system administrator, and DBA.

These concepts originated from startups (and agile methods):

It is undeniable that early‑stage startups are like “hibernating beasts” that remain obscure for years and struggle with insufficient staffing, thus urgently needing DevOps and full‑stack developers.

Unfortunately, the DevOps wave now forces developers in mature companies to assume these roles, compelling them to fill gaps caused by a lack of foundational resources.

Wearing Multiple Hats

Imagine a seven‑person development team in a startup building a web application over a year. When a serious issue arises that requires deep database knowledge, saying “that’s not my specialty” or handing it to a DBA team is impossible; resource constraints force the developer to act as the DBA.

In such environments, a developer may simultaneously be a developer, QA tester, deployment/business analyst, system administrator, or DBA.

This situation is dictated by the nature of startups; some thrive, but developers are constantly deceiving themselves because they must constantly wear many hats, sometimes all of them.

Even when such “full‑stack” developers exist, they rarely work in a normal way. Startups do not merely have developers temporarily assume a role before moving on; they expect developers to continuously hold all roles.

This is problematic because it demands the very best developers.

Talking About Hierarchy

Excellent developers are intelligent, but within an organization there are multiple technical tiers: developers at the top, followed by system administrators and DBAs, with operations and release managers at the bottom.

Why this ordering?

Because each role should be capable of performing the work of any lower tier when necessary.

In startups, a top‑level developer can become a competent DBA, tester, or deployment engineer as needed.

However, the reverse does not hold: a tester cannot perform a developer’s tasks without the required expertise.

Consider a dentist who runs a private clinic and employs a secretary, hygienist, and assistant. The secretary can schedule appointments, the hygienist can disinfect, and the assistant can handle basic tasks, but only the dentist can perform drilling or root‑canal work because of specialized knowledge. Without a qualified dentist, even the entire staff cannot accomplish the job.

Every organization has a hierarchy based on skill levels, and forcing developers to take on other roles can leave no one capable of fulfilling the developer’s core responsibilities.

This experiment, intended to improve software quality, often becomes a farce that overworks the most talented staff while leaving lower‑level positions feeling invisible.

Large companies like this because they can hire fewer people to do the same work.

Consequently, many developers struggle with basic coding tasks such as FizzBuzz because they rarely write code.

Broad but Not Deep

If you are a developer on a medium‑scale software project, you need an appropriate deployment system. Consider the following tools and their pros/cons: Puppet, Chef, Salt, Ansible, Vagrant, and Docker. One of them is completely unrelated.

Specialization exists for a reason: people can only focus on a limited knowledge set. Task switching is costly. Forcing developers into other roles leads to:

Inability to focus on development

Need to acquire a massive knowledge base

Overburden

Moreover, by making developers bear “full‑stack” responsibilities, companies pay far above the market average for the work actually performed.

If a developer earns $100K per year, a company could pay four developers $100K each to accomplish the work of one or two developers (50 % coding, 50 % release management), or hire a release manager for about $75K while two developers focus solely on coding.

Part‑time release‑management developers waste a lot of time when releases are not needed.

Stop Killing Developers!

This approach destroys the “developer” role, replacing it with a “jack‑of‑all‑trades” technician.

Most people enter programming because they love building software. Forcing the smartest people to take on extra roles harms everyone.

Not every company is a startup, and while startups may need developers to wear many hats, the decision to adopt DevOps should be based on actual needs.

9 Companies Practicing DevOps

While many know Netflix and Etsy’s DevOps achievements, the following nine companies also demonstrate impressive DevOps practices:

1. Starbucks

In April 2015, Starbucks launched its #DevOpsTogether initiative, with strong support from the CEO.

2. Ancestry.com

An early adopter of DevOps and Continuous Delivery, showing significant improvements in release frequency and satisfaction since 2013.

3. Ashley Madison

Although its database breach serves as a cautionary DevSecOps case, the incident highlights that DevOps does not always guarantee speed or safety.

4. Etsy

Etsy has built its own tools to enable rapid, frequent deployments, involving the entire engineering organization.

5. U.S. Customs and Border Protection

The U.S. government agencies are surprisingly active in adopting DevOps.

6. LinkedIn

Since 2009, LinkedIn has used automated deployment tools to manage thousands of nodes and services, fostering a world‑class DevOps community.

7. NASA

NASA employs DevOps practices to support software deployment for space missions, evolving since its early adoption of JIRA in 2004.

8. Apple

Apple’s massive iOS updates and September release cycle drive them to seek suitable DevOps tools and talent.

9. Airbnb

As a “third‑platform” company, Airbnb relies on DevOps to quickly release numerous small deployments across its social, mobile, analytics, and cloud services.

For more details on Airbnb’s infrastructure, see the linked slides.

However, not every organization must chase this trend; Jeff Knupp argues in “How ‘DevOps’ is Killing the Developer” that indiscriminate adoption can be harmful.

<code>① https://medium.com/@cloud_opinion/starbucks-announces-devopstogether-2933aad59d74
② http://blogs.ancestry.com/techroots/category/devops/
③ http://www.csoonline.com/article/2917033/network-security/does-devops-hurt-or-help-security.html
④ http://www.networkworld.com/article/2886672/software/how-etsy-makes-devops-work.html
⑤ https://codeascraft.com/
⑥ http://devops.com/2014/04/02/deployment-and-monitoring-automation-glu/
⑦ http://www.slideshare.net/InfoQ/data-infrastructure-at-airbnb
⑧ https://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/</code>

How to Grow Together Happily

Follow the “Efficient Operations” public account for weekly original articles that compile discussion highlights, online talks, and community contributions.