The Doppler Quarterly Summer 2018 - Page 47

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