Why Developer Experience Proves an Effective Engineering Culture
What happens if we categorize it as second-class quality?
“DX should not be focused on; we need to focus on what is best for the user.”
It is a notion I hear often lately. That is wrong in many ways.
If we have a bad DX or don’t take care of it, we will most likely have severe underlying issues in our process and culture. I can’t understand how technical managers can consider setting Developer Experience as a less important requirement.
What determines the final quality of our product? Or its acceptance by the users or clients? Many factors, of course, but one specific driving aspect is the human being working on the product and its outcome—the Software Developer.
After personally employing many developers and working with external teams in Fellowships and mentorings, I see a concerning concordance:
👉 The DX is also bad in companies where Software Development is treated as isolated fulfillment cost centers.
Based on that, I can say that the distance between Business and Development is dangerously large, especially in these companies.
There are two general types of companies I met so far
A: Focused on improving process, product, and culture. ✅
B: Trying to save a tech organization from a dire situation. ❌
There is not much between those, but what I see in (B) concerns me. DX is an apparent factor in this case since, in (B), DX is neither a focus nor a form of NFR (Non-Functional-Requirement) anyone cares for. Instead, we have the following:
Deadlines, deadlines, deadlines (or shall I say miscommunicated Milestones to invoke “motivation”?)
Blameful Environment; Business vs. Engineers vs. Engineers.
Development Shortcuts lead to the Broken Window Effect and severe technical debt.
Burnout, or close-to-burnout states. (See: Overcome burnout with
)Mistrust & pressure
A typical company type for (B) is a Software Agency or investment-driven start-up. Of course, not every one of those, but concerningly many.
What does DX matter in continuously improving companies?
DX is nothing you “do” or “implement… it’s outcome.”
In typical (A)-type companies, enhancement is part of the culture and thinking, and the people working there agree and understand.
A focus on well-being, learning, open-mindedness, and software engineering principles is common ground and an essential aspect – the same applies to developer experience.
DX is nothing you “do” or “implement.” Developer Experience is an outcome, a result. Measuring how much management puts on developers to be happy and intrinsically motivated to achieve great results.
A happy developer who isn't isolated and has contact with the customers and users will be able to identify with the business domain and achieve great results while shaping their work. Remember: You care less if you cannot identify yourself with your work.
If you, as a Software developer, are close to your users, you are the pulse of time, the sense of the “Zeitgeist.” You will have the chance to communicate in different and more effective ways than you could and would do in isolation.
Instead of rushing like (B) companies do, from milestone to milestone in an imperative and pressuring way, an (A) company trusts developers' communication to clear the progress, not blaming anyone if things take longer than “estimated.”
It includes users, clients, and customers. This also means that in a positive environment, developers have more freedom in choosing the technologies they utilize.
This leads to ownership and intrinsically motivated maturity, which drives the product and process. Bottom-up, in a simple term.
This leads to experimentation with methodologies, tech stacks, and frameworks, and very often, the following questions were asked:
How can we make things simpler? (Working with and for average developers)
How can we develop stably and reliably?
How can we focus on what really matters? → UX, for example; you got already?
How can we avoid complexity and unmaintainable code?
🍪 Yes, yes, you are right, this is about Software Engineering.
These are factors of DX that lead me to the conclusion that the following qualities (NFR) are heavily influenced by a positive culture:
Maintainability: This is paramount in a culture that values the developer's experience and user feedback. It involves writing clean, understandable, well-documented code that can be easily updated or modified. A focus on maintainability ensures that the software remains functional and relevant over time, facilitating more straightforward bug fixes, updates, and enhancements.
Scalability is the ability of a system to handle increased loads without compromising performance or needing to be redesigned. A positive culture encourages scalable solutions by default, considering future growth during the design phase, which isn’t the case in deadline-driven development ❌.
Performance: Ensuring that applications respond swiftly to user interactions is critical for a good user experience. A culture that values feedback and user involvement tends to prioritize performance optimizations. Devs will test it next to the users, feel their pain, and improve it out of their own motivation.
Security: In an environment that values contact with humans and user feedback, security becomes a concern for developers, who then integrate secure coding practices and security testing into the development process.
Usability: Direct communication with users enhances the focus on making interfaces intuitive and accessible, ensuring that the software can be used efficiently and satisfactorily. Same as in performance; the developers will know directly what’s happening.
Compatibility: Developing software in a flexible and open environment encourages consideration for compatibility with different systems, platforms, and devices, facilitating broader accessibility.
Testability: A positive culture that encourages experimentation and reliable development inherently values testability, making it easier to verify the software against requirements through automated tests.
Portability: The ease with which software can be transferred from one environment to another. A culture encouraging technology diversity makes portability a key consideration, facilitating deployments across diverse platforms.
Interoperability is the ability of software systems to exchange and use information. Open communication and a focus on user needs often lead to a greater emphasis on ensuring that new software can work seamlessly with existing systems.
Efficiency: Resource usage is optimized under a culture that asks, "How can we make things simpler?" Efficient use of computing resources (such as CPU and memory) means the software does more with less, benefiting both the provider and the end-user.
Accessibility: Ensuring that software is usable by people with a wide range of abilities and disabilities is a natural extension of focusing on UX and inclusivity in a positive development culture.
🍪 Devs start to care for these qualities by themselves because DX is about responsibility, maturity, and loyalty. If you have provided the ground for a positive developer experience to grow, you will see intrinsic motivation and, as a result, a better product and a happier user.
Conclusion – Why I am so strict about this topic
I am harsh on this topic; I don’t negotiate here. If we, as managers, entrepreneurs, or team leaders, don’t put time and energy into a positive culture, then ownership and maturity amongst our colleagues are impossible.
As a result, you will see people leaving your company instead of taking ownership and caring for the company's future, which is an extremely important ingredient for a good product and happy users.
In most cases, it’s sad to see unhappy developers secretly looking for new jobs or managers who cannot sleep because their company is about to fall apart, and everyone seems to run away instead of thinking about how to save the ship.
This resulted from a more protracted process in which culture was absent and “deadlines” defined daily life; pressure, blame, and feelings of guilt were defining aspects.
After a while of being part of a company, employees understand what’s good and what’s wrong. If a person realizes that the tech managers' carelessness becomes their own problem, things start to get very bad.
🍪 There is an easy fix:
Take care of your people so they can care for your customers.
Video: I needed to speak clearly about degrading DevEx as a second-class quality. On-stream with
.Integrate DevEx, which you measure in some way as a quality.
Make sure everyone has enough room to practice Software Engineering
Foster ownership & maturity.
Let developers participate in the feedback cycle and break the barrier between business and engineering.
Don’t force your people to use the tech you think is best; let this result from an experimentation process you are a part of. If you have good arguments against something, tell your people this; don’t overrule. But make sure you find the best solution as a collective.
Be open-minded and listen to developers' comments and concerns. If you don’t, they will notice and stop caring (Broken Window Effect).
Have a great Sunday, and care for the people working with you. Remember, you spend a lot of time with them.
Adrian, snackableCTO 🍪