Over the years, there have been numerous articles about full stack development
and full stack engineers. The conversation has been relevant primarily to soft-
ware development activities (specifically web development), and less so to other
efforts. Opinions on this topic range wildly between the need for deep specializa-
tion in a specific area or two, versus taking responsibility for the entire product
development process and its outcome. We suppose it is somewhat similar to the
question of whether it is better to be an expert in one area, or a “jack of all trades
and master of none.” But we do not believe it has to be one or the other. Your
approach should depend on the operating model you, as a company, implement.
First, let us review the terminology and the concepts. Historically, IT personnel
were organized by functional roles and responsibilities. There were “front end”
folks, who took care of the UI; “back end” folks, who developed the heavy code;
and database administrators who then dealt with the data. Obviously there were
additional roles in the organization, but let us keep this simple for now. The front-
end, the back-end, and the database people all did their tasks and coordinated
with each other at their respective touch points. They may have been really good
at their jobs, but their responsibilities did not reach beyond their domains. That
might have been okay for awhile, but it eventually created, in many organizations,
silo issues, which slowed down both new feature releases and bug fixes.
In comes the concept of the full stack developer. The thinking was that if a devel-
oper can be good at both the front end and the back end, he or she can effectively
remove the inherent silos, streamline the development process and produce
higher quality software, in a shorter period of time. This means a full stack devel-
oper has to be pretty good at all aspects of software development and familiar
with the entire stack - front end UI, coding, networking, databases, etc. Making a
developer responsible for the entire stack helps prevent challenges that can occur
during handoff stages but, more importantly, it changes the accountability para-
digm, as the developer is now on the hook for the whole product. The saying goes:
“if everyone is responsible, no one is responsible.” When things go wrong and a
number of groups are involved, finger-pointing begins. With a full stack developer,
there is only one place to point the finger.
By the way, using a full stack developer does not automatically guarantee that the
code produced will be better than that produced by a team of specialists, and
chances are, it may not. However, full stack developers are certainly incentivized
to do their best, since the responsibility rests solely on their shoulders.
So here is what the full stack developer concept can look like: full accountability
for end-to-end results, reduced silos, removed friction points, faster delivery of
value and shorter feedback loop. Wait. Is this DevOps, or at least something that
closely resembles what DevOps is trying to achieve? It certainly is. That is why
you often see full stack developer roles in progressive, DevOps-minded software
organizations which value short release cycles and speed to market. But it does
not mean that this concept is right for every organization, nor that you cannot
deliver value quickly without full stack developers.
SUMMER 2018 | THE DOPPLER | 45