I remember when we used to only have programmers and system analysts. That’s how it was when I started in the mid-90s, getting into IT and computers.
The main IT guy at the office was both a programmer and an analyst — a system analyst. The analyst would talk to the stakeholders, the business people, to understand the problem that needed to be solved. Then they’d come up with the design for the solution, the different pieces that needed to be built, even the database design. And then, the programmers would write the code to implement it.
At the places where I worked, it was always the same person doing both lines of work: analyzing the system and writing the code.
The Evolution of Titles
A few years later — I don’t remember exactly when — we started talking about developers. Instead of calling people programmers, we called them developers because they were doing both: system analysis and programming.
Then came the front-end and back-end developers. Which was odd to me because, for the longest time, it was just developers, without a real distinction. You had developers who knew how to do both.
But the split made sense for practical reasons. Depending on the team and the project, some developers would focus mostly on the back end, while others would focus mostly on the front end, so that work could be done asynchronously or in parallel. Two people could work on the same feature or user story at the same time, as long as they collaborated and created a contract for how the front end and the back end would communicate. Then they could go off and work in parallel, integrating their pieces later.
What I’ve Noticed About Front-End vs. Back-End
After many years of doing this, I’ve come to a realization: the back end will always outlive the front end.
A well-built, well-designed, well-architected back end will always outlive the front end because the front end is more volatile. And there are good reasons for this.
For one, the front end is the part of the system users are more likely to interact with. It’s where people interface with the system. And as these people understand the system better, as they get more comfortable using it, as they get over the initial challenge of learning where everything is and what the system can do, then they start asking for enhancements or changes.
Depending on what they ask, it may very well be only a change to the front end, not to the back end. That is, if both were created with an architecture that allows for that.
Another consideration: the devices where front ends run change more rapidly than back-end technology. Computers get better processors, more multithreading capability, and multicore. There are things on the client side. Monitors get bigger, and the resolution gets better.
But also, there’s the situation where the screens get smaller — smartphones and tablets. Those also need front ends, but they’re a different kind of interface from those on a regular computer. We’re not using a mouse or an external keyboard. We’re tapping on a screen. We’re using touch.
With all these front-end changes — due to devices, computers, and screens — the back end may not have to change at all. Or when it does, if well-structured and architected, it can be changed with minimal changes. In some cases, it may be an addition. Maybe it’s creating a new view model to map data from the database into what the new UI for the new device requires. It could be a database view or a read model in an event-sourced system. Those are additive, which are usually easier than changing existing code.
The Limitation of Specialization
I’ve been thinking that some developers focus solely on front-end development, and others solely on back-end development, which can be somewhat limiting.
Both of them should really focus on neither. Yes, they may have preferences or be better skilled at one or another, but at the end of the day, those are just pieces of technology.
In both cases, they should learn to work with people, to work with businesses, and to come up with the best solutions.
For those on the front-end side of things, they should get very much in touch with user experience design, empathy, and all of these techniques and approaches to understand the problem being solved and then come up with better experiences for it. And then from there, get to the UI design.
For the person who is mostly on the back end, that could mean understanding the problems you’re trying to solve, the events—the business events that happened, and the domain events—and designing it to capture users’ intent, people’s intent, and business intent. Design around that first, before thinking about persistence concerns, data replication, and those things.
And for that, getting to learn domain-driven design, more specifically the strategic patterns, learning about context mapping, and the relationship between the different types of domains, ubiquitous language. That is very important.
For both front-end and back-end developers, I believe that if they view behavior-driven development from the standpoint of people’s behavior, rather than system behavior, that would be best. Because now they focus on the people and the problems that need solving, they put their heads together to come up with the best solution.
What This Means in the Age of AI
Now, in the age of AI, a person who can do that — who can have the empathy, develop the empathy, articulate thoughts, and facilitate conversations with people to then come up with the designs for the behavior and the experience, to a point where they can describe it — can then collaborate with AI to refine that understanding.
And last but not least, work with AI for AI to do the actual work of proposing mockups, wireframes, and high-definition prototypes. And from there, creating the actual implementation on the front end, on the back end, creating what is technically necessary to pull it off.
No longer would front-end developers spend a lot of time figuring out CSS, styles, and misalignment in the design. Let AI figure that out. Do that kind of work.
Same thing on the back end, trying to address some complicated business logic. Let AI write that logic. As the human in the loop, make sure that the acceptance criteria are well-defined, the user stories are well-defined, and the examples are well-defined. Have documented ways to write good specs for the automated tests, and let AI implement the solution.
The Real Skill
The labels — programmer, analyst, developer, front-end, back-end, full-stack — they’ve all been useful at different times. But they’re just labels for pieces of technology.
What I’m noticing is that the real skill, the one that matters more now than ever, is the ability to understand people and problems. To design with empathy and intent. To articulate what needs to happen before worrying about how it happens.
The technology will change. The devices will change. The tools will change. AI will handle more of the implementation details.
But understanding what to build, and why, and for whom — that’s still on us.
Leave a Reply