It starts with "they have nothing to talk about."
The Great Divide is an essay by Chris Coyier, written in January 2019. The post tries to explain a recent effect that is happening in the Front-End community. It goes like this: on one side, developers heavily skilled in JavaScript; on the other, developers heavily skilled in HTML, CSS, Accessibility, and Web Design. Although they all call themselves "Front-End" developers, they don't share the same interest or skills.
According to Chris: "They have nothing to talk about."
However, there are other divides lurking around the software world beyond the Front-End. Some of those divides have been happening for decades, others have been since a few humans in suits coined the term "Software Engineering" 50 years ago. Besides, there's one epic divide; one that shouldn't exist from the perspective of any reasonable human being.
This post is going to talk about important divides in web development that can impact teams, communities, and organizations.
There are older and stronger divides than the ones you see in the Front-End community nowadays. Let's talk about them.
The first divide is Front-End vs. Back-End. Like "The Great Divide," there are many web developers who can create great websites. In one side, people heavily skilled on how the browser works, the "Front-End" developers; in the other, people heavily skilled on how a server works, the "Back-End" developers.
The idea of "Front-End" in the context of the Web comes even before jQuery. At that time, we used to create websites inside tables and had to come up with creative CSS hacks to support the almighty IE 6. Although it seems like a long time ago, the practice of "Front-End" is considerably new, not more than 20 years.
In another hand, "Back-End" is as old as computers are.
If you are used to building "Back-End" applications, you tend to learn a myriad of fundamentals essential for developing software that smart programmers already discovered decades ago. Those practices are not looked up by developers who are more interested in Front-End technologies. The same occurs in the opposite. If you are used to building "Front-End" applications, you tend to learn a myriad of fundamentals of how the browsers work in which Back-End developers are not interested.
Back-End developers don't care about Front-end. Front-end developers don't care about Back-End.
That separation of interest creates a massive gap of knowledge on both sides:
For technology communities , it prevents the sharing of experiences. It hinders a significant potential for technological innovation.
For example, say you're in a “Back-End” language meetup. In that meetup, it's more likely you'll only find Back-End developers. It's not hard for an environment like that to create a Contempt Culture against those who prefer Front-End. Imagine in the same meetup there are a few junior developers who are starting their career in software. If they hear contempt and lack of interest towards Front-End, they'll also despise anything related to that in the future. This separation creates an environment which puts a limit to what those junior developers can learn.
For organizations , it creates incentives for each team to duplicate logic in the Front-End and Back-End.
For example, you have a switch for the status of a Workflow in the Back-End: “PENDING” and “CANCELLED.” Given Front-End developers work separate from each other, it's very likely you're gonna end up with the same logic in the Front-End code. Later on, if you want to create a new status for the Workflow, you'll have to change both Front-End and Back-End instead of changing in a single place.
If you're a Front-End developer, you tend to create systems with heavy client-side JavaScript code and light server-side. If you're a Back-End developer, you tend to create systems with heavy server-side and light client-side JavaScript code.
I’ve partially written about this divide in a post that shows how the Back-End and Front-End separation can drive you to create useless code. You can see more examples here: Front-End Separation And The Irrational Love For Curly Braces.
The Front-End and Back-End separation create incentives for developers to work in isolation, duplicate logic, and develop everything either in the browser or the server.
Another divide is between Infrastructure Operations and Product Development. In one side, people heavily skilled on how network protocols and hardware works; in the other, people heavily skilled in software architecture and design.
If you have more interest in infrastructure operations, you tend to de-prioritize learning the software design principles associated with fast and sustainable product development. You tend to focus on computers and the technological challenges of how to keep them running: high availability.
Having the interest to keep computers running helps you to learn how to design reliable software and build observability for the hardware. However, it doesn't help you to learn how to design systems that can provide availability from the user perspective. For example, it doesn't make sense for the server to be up and running if the user has to watch a spinner for one hour to get what they want. That's an outage from the user perspective.
Your daily coding routine as an Infrastructure Operations developer might be to write small self-contained Bash Scripts or infrastructure code such as Terraform. Therefore, learning automated testing techniques such as TDD doesn't make much sense; neither how to change your design to be more testable.
If you are more interested in product development, you tend to miss essential fundamentals regarding physics. You fall easily into the 8 Fallacies Of Distributed Computing. You tend to optimize for great design and programming principles that can increase maintainability and reduce the cost of programming (SOLID, XP, Connascence, Cohesion). However, you also miss the opportunities to learn about the challenges of the physical boundaries computers operate in the real world. As people say: "There's no cloud, it's just someone else's computer," and the computer is physically located somewhere in the real world.
The Infrastructure Operation and Product Development divide create incentives for developers to not understand the physical challenges of hardware and for operations to not understand the economic costs of software.
Let's not forget about another significant divide, one that happens mostly in big companies: the divide between User Experience and Front-End Development. In one side, people heavily skilled to create the user experience and the visual design of the system; in the other, people heavily skilled on how to use HTML, CSS, and JavaScript to create a live website for production.
From the designer's point of view, they build a user flow based on customer feedback along with the visual artifacts to match the company's brand. However, when they hand that over to Front-End developers, the developers end up complaining about how the final result doesn't fit their internal components library. Also, they complain about how the elements involved in the intended flow of the designer is hard and costly to produce. The result is considerably different from what the designer envisioned.
From the developer's point of view, they receive a beautiful flow and design. However, the design shows zero understanding of development costs associated with it. Some components are reusable, but the design is not using them. The team can change some parts of the UI, but other parts they can't touch. For example, the designer may create an onboarding tour experience that spans across all components of the page. However, the designer doesn't know the team only owns one iframe inside the main website. It's technically and politically impossible to have an onboarding tour experience than spans across all components without rewriting the whole system.
The UX and Front-End divide creates a situation where development complains about the designer, and the designer complains about the developer
There are many reasons these divides happen. The main one is because the company and the software communities base their roles on the technology:
- “Front-End JavaScript developer.”
- “Front-End HTML/CSS Developer.”
- “DevOps Engineer.”
- “Back-End Developer.”
- “UX Designer.”
They don't base their roles on business capabilities:
- "Online Sales."
- "Customer Recovery Department."
- "Automated Billing."
- "Employee Experience."
- "Online Marketing."
Everybody believes the cost for one person to learn the most important fundamentals necessary for software development is too high. For that reason, the market creates incentives for people to take shortcuts by specializing so that they can get a job quickly.
The best shortcut to enter the market is to specialize
In summary, there are many technologies divide in software development besides JavaScript and HTML on the Web; some of them are:
- “Back-End” and “Front-End”
- “Operations” and “Product Development”
- “UX Design” and “Front-End Development”
As a programmer, it's paramount to understand the fundamentals behind software development, not to focus solely on one technology stack. That allows you to see all the boundaries of what's possible and what's not possible; to understand the tradeoffs of one technical approach over the other in a given business context.
There's a purpose on the code you write towards the problem you're trying to solve. The purpose is to create value, not merely to write code.
That is programming.
As a company, it's paramount to create a culture of collaboration. If there are multiple roles required for an essential piece of work, try to bring them closer together in the same room, at the same time, in the same computer. Create a culture of Code Review , Pair Programming, and Mob Programming.
As a programmer, learn the fundamentals; as a company, collaborate.
Besides all these, there's an epic divide which happens in every large scale organization; a divide that should never exist.
It's the divide between the ones who build the software and the ones who use it.
It's The Divide Between The Programmers And The Customer .
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook, or Github.
Thanks to Allan Denot, Diego Freitas and Wael Emara for their insightful inputs to this post. Thanks to Chris Coyier for "The Great Divide."
Wanna chat in person? You can find me in the Sydney Software Crafters meetup.
Top comments (0)