The Role of the Full Stack Developer in Large Projects
A little less than two decades ago, things were simple. Software developers were primarily engaged with developing software end-to-end. There was no major distinction between the people creating the UI, and those developing the backend. Most applications were either desktop monoliths, or desktop “clients” that communicated with some kind of server backend, over the network:
In either case, early development tools provided enough building blocks, for developers to create everything under the same project. This resulted in homogenous, but boring, and unappealingly looking applications. Back in those days, Web was, for the most part, a bunch of static pages, linking to one another. With some eccentric exceptions, most of them resembled the look and feel of their blocky Windows counterparts.
A few years later, during the early and mid-2000s, came the Web 2.0 revolution, which swept everything away. Rather than remaining single-purpose monoliths, software applications turned into distributed “services”. The traditional model of installing hundreds of megabytes on one’s computer, got replaced by typing the URL of one’s favourite web app in a Web browser. With time, the relevance of the underlying operating system diminished. In a little less than a decade, the browser became the OS — for many, the one and only window kept open at all times.
Web 2.0, and the following foray into mobile, forced significant changes, into how the new wave of software applications was supposed to be built. For once, backend and frontend development became separate disciplines, each requiring a different set of skills and expertise. In fact, in recent years, the gap between frontend and backend has become became so huge, that a new discipline has arrived, intended to glue those pieces back together — the role of the full stack developer.
Misconceptions
If you look at job listings nowadays, it seems like just about everyone is looking for developers who can work on all aspects of a project. Many companies call this a “full stack” position, and in fact many organizations already have opened such “full stack” positions across their teams. I find this idea of a “full stack” developer being a “know-it-all” whiz, flawed, and dare believe that relatively few organizations have managed to raise the new role to its full potential. This post tries to shed some light on where the full stack developer should ideally stay within a team, hoping to help dissolve those misconceptions.
There are two very contradicting misconceptions that get tossed around, when it comes to defining what a full stack developer is, and the full stack is supposed to do:
The full stack developer knows a bit of everything, so our company will save on human resources, by hiring a few of them.
or
The full stack developer knows a bit of everything, but nothing in particular. A full stack developer would only be a burden for our team. She would never be able to go into the the level of detail, the way a frontend, or a backend guy would do.
Neither of these is 100% wrong, but neither is correct either. A full stack developer is not a whiz kid, who could magically replace a team of backend and frontend experts. No. Though a full stack developer is supposed to understand both worlds, her role is not to replace, but help bring those two groups closer together. In fact, a good full-stack developer is a bit like the bass player in a rock band:
Full Stack = Bass Player?!?
Playing bass in a rock band is an often underrated, but an incredibly important role. Unlike the vocalist or the guitar player, the bassist takes little credit for her performance. With the exception of jazz and funk music, the bassist rarely does have a prime time on her own. She won’t always pull out a breathtaking solo, the way the lead guitar would do. She also won’t always engage the fans, the way only the vocalist could do. Yet, a good bass player will always be there, gluing the entire band together.
“A bass player is a bit like the mortar between the bricks.” (David Elefson, Megadeth)
Have you ever seen a good rock band with a bad bass player? Or worse, a self-respecting rock band with no bass player at all? No? Well, there are a few good reasons for this:
First of all, there is a huge sound spectrum gap between drums at the low end, and high-pitched guitars and vocals at the other one. This gap is usually filled by the bass. Taking the bass out of the equation, leaves a shallow tune, left of “soul and spirit”. You can still listen to it, but it will always feel as if something is missing.
Having a skilled bass player in the band though, is just as important for the other band mates, as it is for the audience. One of the hardest things in playing in a band, is playing in tune and sync with the others. This is where the role of the bass player as a coordinator and a hub between the players is so important. She keeps the tempo and rhythm set by the drummer at all times, laying out a foundation of the main melody, which stays pretty much the same throughout the song. This allows the guitar player to pull off a beautiful solo, without fear of the sound breaking loose.
Back to the Team
A software team nowadays, looks pretty similar to the rock band, I have been describing so far. You usually have pure backend and frontend developers, covering their own spectra of tasks. If the project at hand is well specified, both sides typically agree on an API and keep doing what they do best, sharing little concern of how the other side is doing things.
As we all know though, very few things in life work in their ideal state. Much of the time, developers spend clearing out the misunderstandings in their communication. They do this at lengthy meetings. If you have been in such a meeting, you know how little respect a frontend guy would pay to your detailed proposals for speeding up the backend. Let’s be honest though, when it comes to frontend guys explaining their problems, it’s your turn to start looking at your phone. That’s just the reality. More often than not, the visions of the two sides deviate, and the only way to bring them back on track are more meetings, and refactoring efforts.
This is where introducing a full stack developer to the team can be a huge boost for the team’s productivity. Not necessarily in terms of bringing new features to market, but more in terms of reducing team friction, and cutting down the refactoring efforts.
The full stack developer can understand the concerns of both sides, and translate them into code that takes the input from one side, and makes it easy for the other to process. In large projects, this usually involves the creation of a thin layer of abstraction that sits between frontend and backend. This layer, also known as “middleware”, should hide the implementation details of both frontend and backend, and provide a seamless flow of data from one end to the other.
Where developing a middleware traditionally assumed using the backend technology stack, I have been seeing a shift towards bridging the gap even further. It is not a surprise, to see a mixed stack on the server, where the core backend might be Java-based, with a middleware sitting up front, based on NodeJS. For large software projects, pulling off such a feat can have the effect of skyrocketing the project, or bringing it down to earth, if done improperly. This is one place, where having a team member who is proficient across the entire stack, can make a huge difference.
Not only that. Full stack developers can be the drivers of new feature development. Though one can hardly develop a new feature across the entire stack alone, it makes sense to let full stack developers build a scaffolding, which backend and frontend devs can later work on. Again, this can save time and communication effort early on, as well as refactoring efforts later on in the project.
As you see, the role of a full stack developer in a large project is far from being the expert or the whiz kid who can do everything. Similar to a bass player in a rock band, the role of the full stack developer is much more the one of a communicator and coordinator between frontend and backend. It is not meant to replace any of those roles in the nearby future, but rather support them, and build bridges between them. I hope all of this makes sense to you too, and you will take it into consideration, the next time your organization decides to bring a full stack developer on board.
Disclaimer: I am both a full stack developer and an avid bass guitar player 😉
This post also appears on my blog
