What Do I think of “Full Stack” Development and the DevOps Movement?

Once again, I’m doing reader question Monday on a Tuesday.  I have no good excuses this time, either.  We arrived last week in San Diego, which is beautiful.  So, I’ll just flat out admit that I spent the weekend strolling beaches, eating lobster tacos, drinking craft beers, looking up at the stars and just generally enjoying life in a way that involved no writing of blog posts.  I regret nothing.

So let’s to reader question Monday on a Tuesday.  This is actually a question that just came in today as I was gearing up to write about TDD and remote teams.  It caught my attention, so I’ll give about the fastest turnaround time I’ve ever done on a question.

I recently stumbled upon this article: https://jeffknupp.com/blog/2014/04/15/how-devops-is-killing-the-developer/

Which seems to lump Full-Stack dev in with DevOps, and discards DevOps, on the premise that the full-stack dev is good-for-the-org-bad-for-the-dev. I know you’ve weighed in against the full-stack dev with preference for specialization. I wonder if you believe this also means DevOps is DOE, or if there’s still room for DevOps in your mind (or perhaps more broadly speaking, for startup-like, feature-teams so often found in Agile/Scrum orgs)?

If you don’t like DevOps, what do you recommend instead to manage the entire release automation process, and everything else it entails?

Alright.  There’s a lot for me to work through here, so let’s break things up a little.

DevOps (And Full Stack) is Killing “The Developer?”

First, let me recap briefly the article’s thesis.  And I’m really going to try to be gentle here and non-objectionable.  I trade in blog posts for a living these days, and slugging it out with random people on the internet has worn as thin as it can possibly wear to me.  I’d really rather not argue with this Jeff Knupp, and I can certainly empathize with waging a vigorous campaign to make your own job more fun.

The article’s thesis is, essentially, this, from the perspective of a salaried employee in the enterprise.

I hate the DevOps (and full stack) movements because I like writing code and they result in me writing less code.

The author might object to this thesis, but that’s really the message.  It asserts the superiority of the software developer as compared to other individual contributor roles, and then argues that DevOps and full stack (and forced skill diversification in general) are good for the employer, but bad for the employee.  (Although he then curiously argues that it’s also bad for the employer, since they’re “overpaying” for non-development labor.)

In short, I could paraphrase the line of argumentation fairly easily.  Software developers are more important (and smarter) than anyone in other roles, which makes their time and labor more valuable.  And because their time and labor are more valuable, they should specialize in software development, rather than wasting their talent on operations, QA, DBA, or any other breeds of lesser tasks.

This is a Different Definition of Specializing than Mine

Again, out of my lack of interest in arguing with Jeff, should he ever wander by, I won’t bother weighing in specifically on what I think of this line of reasoning.  But let’s establish that the type of specialization he’s referring to (writing code) is much different than the sort of specialization I refer to.

If you refer to this post, you’ll see that “specializing” in software development is closer to what I’d refer to as a competitive advantage.  A specialty has to do with your value proposition, and that article offers no take on the value proposition of commodity app dev (it just assumes it in spades).

Let’s draw a crystal clear distinction.

• His position is that “specialty” refers to “the thing I practice and get the best at.”  He indicates that people who know how to write application code should thus “specialize” in writing application code.
• My definition of specialty is extrinsically focused.  Your specialty is who you help do what.

So to circle back to the reader question, understand that Jeff and I both take issue with the idea of identifying as a “full stack developer,” but we do so for diametrically opposite reasons.  Jeff objects to this because he really, really likes writing Python code and the other parts of the stack take him away from doing that.  I object to the term because I think it commoditizes you as a miscellaneous generalist.  But you know what?  I think saying “I’m a Python developer” also commoditizes you as a miscellaneous generalist.

What I Think of DevOps and Full Stack Developers

At this point, I’ll transition away from referring to this article and offer my own opinion instead.  I went into a lot of detail because it was necessary to unpack the nuanced consideration we give to the idea of specializing.

As I’ve said, I object to the idea of software developers identifying themselves as “full stack developers.”  But this isn’t because I think they should pick some slice of a stack (e.g. writing Python) and refuse to do anything else.  If anything, I object to this being too narrow.

We learn something like “the LAMP stack” and then call that enough.  Why is anyone paying us to build this web app?  Are we helping someone save money?  Make additional money?  We blow these questions off as “someone else’s concern” and then call ourselves well rounded by virtue of knowing how to use an operating system, a web server, a database, and an application language or two.

So what do I think of the term “Full Stack Developer?”  I find it ironic.

What about DevOps?  To me, that one’s a no-brainer good thing.  Historically, we’ve been able to write code whose production performance fell under “not my problem.”  The DevOps movement makes it your problem.  It adds badly-needed accountability.

The Outmoded Model of Complex Systems

The Lean Startup had a chapter in it that talked about the power of small batches.  It talked about the task of sending out hundreds of newsletters.  Conventional wisdom (based on principles that emerged in manufacturing with the Industrial Revolution) encourages you to “specialize” and batch.  Have one person write the letters.  Then have another fold the letters.  Yet another person stuff the envelopes, and another one stamps them.  By concentrating on their individual tasks, everyone gets really good at them, and the whole thing becomes more efficient.

Of course, it actually doesn’t work out that way.

Everyone becomes super efficient at the thing they do, while the enterprise as a whole suffers.  The individuals feel great about their work, while delivering relatively inferior/inefficient value.  This is the siren song in Jeff’s post.  If your goal is to feel more efficient without caring about eventual value delivered, then it absolutely makes sense to optimize for doing only specific tasks.

But if your goal is value delivery (what I call your specialty), then you need to think about things differently.  You need to think less about how you feel and more about those who pay you feel.  Calling yourself a “full stack web developer” is all about you.  Avoiding DevOps because you don’t like the “ops” part is all about you.  If you want to truly specialize and to have a good career, focus instead on who you help.