Photo by Alex Padurariu on Unsplash
I've seen a trend across my industry over the past several years that I was at first complacent with, but I am now growing to dislike with increasing fervor. It started simply, gently, and with great concern for the cognitive overload of web developers, who historically have held wide knowledge about a vast array of subjects to do our job. To be effective, most web projects require knowledge of at least:
- SQL
- a Server-side programming language
- HTML (and modern semantics)
- Accessibility
- Styling with CSS
- Javascript for Interactivity
- Web-server config (including the webserver, language/interpreter, underlying OS, database config, etc. You could also include the mountain of information about properly securing an internet-connected server).
Those are the basics of the 'web 2.0' that powers so much of the internet today. Even a basic blog like this one is running on top of a full LEMP stack, using Drupal to load these words out of a SQL database, pass them through templating and rendering engine, to spit them into a page where many, many lines of CSS and Javascript snazz them up to make your reading experience at least mildly pleasant. Thankfully in my case, a bunch of that code is open source, and very, very little of this site code was actually written by me (giving up a fully custom theme to just use Drupal's default Olivero was a difficult decision that in hindsight, I am glad I made, I can focus on giving you my thoughts rather than spending what little free energy I have to make the site look more unique).
The trend I am talking about is the trend to fully separate the full-stack developer into its two constituent parts, the frontend developer, and the backend developer.
The business case for increased specialization
I understand the desire from multiple angles. From the business owner and manager's perspective, specialization often leads to efficiency gains. Developers who specialize in solving a smaller discrete set of problems usually develop the efficiency to repeatedly solve that same problem at faster and faster rates as time goes on. These developers are no longer context-switching, they are not forgetting how to do things, because they are doing the same thing over and over again.
Historical precedence
This is not a novel concept for businesses, and it is not unique to web developers. A reading of that great and weighty tome Capital by Marx will show a very deep and detailed understanding of this process that dates back to at least the dawn of the industrial age.
When the vast majority of commodity production in the modern world moved from "handiwork" to "factory production", workers moved from artisans that often owned the entire process of producing their commodities (from "raw" materials all the way to finished goods, ready for exchange) to figurative 'cogs in the machine' that repetitively perform the same action over and over again and produce no finished articles solely by their own labor.
This lowered the training and skills needed by individual workers, allowing them to be hired and fired more easily as demand for commodities fluctuated. As the knowledge and tools of production were both removed from the worker's sphere of control. Power rapidly shifted to the owners of the machines, the owners of Capital.
With the introduction of factory labor, huge gains in efficiency were achieved through specialization and centralization of the means of production in dedicated-purpose factory machines. The most expensive part of the production process is typically the labor cost paid to workers, which factory automation made cheaper and rarer per finished commodity.
This is obviously a desirable thing for not only business owners and managers, who are required to seek increased yields from invested capital, but also for consumers of goods, who are now able to acquire those goods at a higher rate for a lower cost.
Specialization is a compelling proposition for businesses for this reason, there is no malice in this truth, there is only a logical coldness in the need to improve yields to compete in a Capital driven society.
The case for easing the overwork of developers
On the flip side, there is a valid desire for some developers themselves to embrace specialization. The act of choosing a specialization (frontend, backend, database, AI, pokemon, whatever) intentionally narrows the number of topics they have to maintain knowledge of.
Not every person is equally capable of learning a wide variety of subjects, which is something that ADHD full-stack devs like me often forget. For some workers, this can help them to quell the feeling of overwhelm when a request comes in that they are not immediately familiar with and the anxiety they may feel when delivering on a request that is 'outside their wheelhouse'.
Additionally, not every worker seeks to find the same level of engagement from their primary vocation. In order to 'drink from the firehose' of knowledge that can sometimes be required to be a fully competent and independent 'artisan', capable of producing a commodity such as a web project all by one's self, one must often use a not insubstantial share of their personal time to achieve a level of competence in so many disciplines.
This naturally means less time to pursue other leisure time activities, and I suspect that many of my colleagues who prefer their specialization are keen to use their free time for completely different endeavors, and that is a wonderful thing.
My argument(s) against forced specialization
Up to this point, I've tried to lay out what I understand are the very legitimate reasons that specialization is being pushed in our industry as it has so many others. I have tried to develop the best understanding I can for why this sentiment seems so popular, so now it is time to turn my attention to why this trend irks me so much.
Limiting a developer's impact
One of the simplest concrete problems I have with this trend is that it is cutting off a huge amount of potential impact that many developers can have on a project. When some of your developers are capable of completing both front-end and back-end work, and you have relegated them to one specialty or the other, you are reducing the overall impact that person can have on the project artificially to force them into a smaller role than they are capable of fulfilling. This is both potentially frustrating for them as a developer, and bad for your project and team. The developer may feel stifled or possibly less valued/respected because they know they are capable of more than they are assigned. The business may also be missing out on creative solutions that this developer may come up with that the dedicated specialists don't see.
Reduced team flexibility and agility
When team members take on rigid roles, you do gain a level of certainty in responsibilities, but you trade that for a reduced ability to adapt to changes. If a given iteration has a dirth of frontend work to do and very little backend work, you may have your backend developer sitting idle while your frontend developer is sweating bullets trying to ship on time. Often this can be planned for, and an even spread can be achieved, but sometimes this just isn't in the cards. Were both developers in this scenario full-stack, they could adapt to the natural flow of requirements and simply work together towards fulfilling the goals set forth. When one developer is weaker in a certain area, they could pass that request off to the other, or if they are too busy, they can get it as far as possible themselves and seek a little guidance later. Simpler frontend tickets can go to the developer with less frontend expertise and vice-versa for the weaker backend developer. What we gain by using full-stack engineers is flexibility and agility.
Trying to use big company techniques in the wrong context
Specialization became a large part of factory labor for a number of reasons, and one of those reasons is scale. Factory equipment was not mobile, especially during the early industrial era, when machines were connected to dedicated steam power sources that were co-located with the factory, long before electricity and small efficient motors were available that would work in someone's home.
Specialized single-purpose machines and colocated factories go hand in hand with massive scale. There is more to say about how this centralization of the means of production also robs workers of their financial leverage, but for the purpose of this article, I am only concerned with the fact that specialization is a tool that is better suited to larger organizations, and can quite frequently be a detriment to smaller organizations.
This is a common problem in the software industry, where we read books about how Google or Amazon built their empires, and then try to repeat these business and software practices in our small teams, only to be flabbergasted why we haven't joined Bezos and Zuck in the three commas club. We adopt tools like Kubernetes and React when our projects don't need them, we run decoupled Drupal so we can be cool, and completely hamstring our projects by massively increasing the iteration cycle to ship basic features.
Alienation of the developer from their work
Okay in the final argument here, I am going to shift focus from talking to the business folks to zero in on the developers themselves, my fellow workers.
Brothers, sisters, you are a part of a unique profession in a unique time in the history of human productivity. Those of you who like me work almost exclusively with open-source web software have access to the real means of production in an almost unprecedented way.
We have the capability, through our own labor, to bring fully-fledged software products to the market with tools we can buy and own ourselves. This is something that has been increasingly difficult for workers to do since the dawn of the Industrial Revolution and the introduction of factory production systems.
For the last several generations of workers, very few professions have had the opportunity to exclusively own the means and produce of their own labor. Outside the ownership of these things, the ability to own even the entirety of the labor that went into a product itself is rare, even if you are using a company computer, and the software at the end of the day is owned by the company that employs you.
Losing this ownership over the end products you create causes something Marx calls alienation of the worker. While this effect is certainly not 100% accepted science, I firmly believe that this is an important concept that both leads to the disempowerment of workers as well as discontent and unhappiness as well.
Ultimately, I believe that modern-day software developers, especially those of us who are working with open-source software on the web have a very unique opportunity that will almost surely not last forever, and with "AI" knocking at our doors, perhaps the next large leap-forward in the ever marching machine of automation, the time to seize on this unique opportunity is rapidly coming to a close.
With this opportunity, I'd like to believe that workers have an unprecedented window to influence society in ways we haven't seen in years, and likely won't see again for a good long while.
Comments