.svg){kind=logo}
Menu
Close
For years, the designers vs developers divide has been a defining tension in tech. While both sides are essential to delivering great products, the tug of war between creativity and code often leads to bottlenecks and compromises.
For some, the key to bridging the gap is constant collaboration. User experience (UX) designer Ix Techau says, “We're nothing without each other. The ‘king’ will be a UX designer sitting next to a back-end developer.”
For others, the solution goes much further than sitting next to. The UX designer should become the back-end developer.
Enter the full cycle developer: a professional who can handle both the visual and technical aspects of creating digital products.
Could this hybrid skill set finally bring an end to the rivalry between design and development? Or does it go too far?
A full cycle developer is responsible for the full life cycle of software development (SDLC) and proficient in every stage, from design, development, and testing to deployment, maintenance, and support.
One minute they might be creating software to solve a business problem, the next writing test cases, and the next automating the operational aspects of a system. Full cycle developers apply engineering discipline to all areas of the life cycle and evaluate problems from a developer perspective, using systems-focused thinking rather than humans-focused thinking.
Netflix created the full-cycle developer model to eliminate silos, communication overhead, and bottlenecks between different specialists. Instead of having designers, developers, testers, release managers, and site reliability engineers (SREs) who each own a slice of the life cycle, Netflix decided to turn everyone into generalists. Generalists with much broader responsibilities, who have a reasonable depth of understanding of each area rather than mastery in just one.
No. The role of a full cycle developer is much broader. They’re responsible for overseeing the full SDLC, which includes planning, design, development, testing, monitoring etc.
A full stack developer is usually only involved in the development stage of the SDLC. Full stack means they can code all front-end and back-end layers of an application, of which there can be lots.
The roles are similar in that both full stack developers and full cycle developers are generalists. Full stack developers are expected to have some knowledge of all the layers of development, rather than be a master of a few.
There are a couple of key benefits of having full cycle developers.
A full cycle developer can provide a comprehensive perspective on a project. Understanding the big picture enables them to anticipate problems and course-correct, prioritize features and optimizations that will have the most impact, and build solutions that are aligned with business goals.
Full cycle development can speed up end-to-end progress by eliminating silos and bottlenecks. Yes, you could argue that grouping a bunch of specialists together can reduce silos. But having different people doing each job adds communication overhead and inhibits the effectiveness of feedback loops.
For example, if deployment and monitoring are handled by separate people, developers have to request changes and wait in queues. A full cycle developer can simply adjust the code and redeploy by themselves.
I personally think there are more cons of full cycle development than there are pros.
Netflix themselves acknowledge that full cycle development has its downsides. Being a jack of all trades can be uncomfortable and unfulfilling and many developers just want to code and be experts in that specific field. Likewise with many designers, testers, and SREs.
It’s like me being asked to be a graphic designer as well as a copywriter. No, thanks. My specialty is words. You could try and make me learn Photoshop or Figma or send me on a course to make me better at drawing. But one, I’d hate that, and two, I’d never be as good as my fellow CollabSoftie Claire Rojek, who specializes in it.
The breadth that owning the full SDLC requires increases a developer’s cognitive load and means they have to balance more priorities each week than if they just focused on one area. It also requires both interest and aptitude in a hefty range of technologies.
Netflix say they mitigate these things by having a rotation of devs taking turns handling deployment/operations/support responsibilities. But they acknowledge the risk of burnout when full cycle development isn’t done well.
Full cycle developers use systems-focused, not humans-focused, thinking. But good UX design requires humans-focused thinking. At the heart of a designer’s day to day is empathy with user needs and behaviors.
A focus on systems can result in user-hostile solutions that make sense from a technical or business perspective, but feel unnatural or cumbersome to use. For example, a perfectly structured navigation system that doesn’t match how users actually search for information.
If you only have generalists delivering products, sure, you might deliver them faster, but will they be as great as they could be? Probably not.
It’s like primary care physicians/general practitioners. They can diagnose and treat all kinds of conditions, but they won’t always get to the heart of the problem because they don’t have the expertise. That’s why they refer people to specialists.
If every team adopted the full cycle development model, it would be like having no specialists in healthcare. Complex illnesses would go untreated and the quality of care would decline. Likewise in software, complex user problems would go unsolved and the quality of products would decline.
“I think people excel at development or they excel at design, not both. I don’t think becoming a full cycle developer is the mainstream way to go.”
Joèl Soedito, Full Stack Developer, BookThat
I read an article about a game designer who learned to code so he could go it alone and build games without having to work with developers. In effect, he became a full cycle developer to avoid collaboration.
And that’s kinda what full cycle development is. It’s not a way of getting designers and developers to collaborate better. It eliminates the need for collaboration by making designers and developers the same.
Maybe if you have people willing to have a go at everything, full cycle development might work. It obviously works for Netflix. Also, startups and small companies could benefit from having a full cycle developer because their resources are more limited. However, if your chief concern is product quality, full cycle development probably isn’t the answer.
Netflix say their model was inspired by the DevOps movement. DevOps was about integrating development and operations and avoiding wasted time from the two teams throwing responsibilities over the wall at each other. Just like what happens between development and design in a traditional waterfall-style design handoff.
But DevOps wasn’t meant to be devs becoming ops engineers and vice versa. The intention was that development and operations would learn what the other does so that they could collaborate better. In some cases, operations were encouraged to adopt SDLC practices like infrastructure as code (IaC) and automated pipelines, and devs were asked to take on a few concerns they’d traditionally leave to ops, such as security and performance.
This is pretty similar to the call for designers to learn code and developers to learn design. But in DevOps, you’d still have operations-focused engineers and feature-focused developers who work together to solve problems. By the same token, you can have designers and developers, sharing a concern for both usability and function, who do the same.
So, the answer to better developer-designer collaboration isn’t to blend the skill sets. It’s to broaden them.
A former lawyer, Berry loves theme parks, has published a sci-fi conspiracy thriller trilogy called Million Eyes to rave reviews, and is a specialist in writing content for tech companies.
