Developer friendliness, often seen as part of developer experience, covers measures that never make it into the production system and exist only to make everyday work easier for developers, testers and everyone else on the project. Typical examples are test interfaces, mock services and automated resets of test environments. The short-term effort pays off through lasting time savings and better software quality.
Key Takeaways
- Developer friendliness measures cost time up front but pay for themselves by permanently speeding up repetitive tasks, which frees up more capacity in the long run.
- Building a REST interface as a test entry point for Kafka consumers became routine after the first day and from then on took only about half an hour per interface.
- Making manual testing easier automatically improves quality, because tests get run more often and with less friction.
- An internal mock service for external REST dependencies protects local development and automated tests from failures of external systems.
- When a development team removes sources of frustration, the mood in the project improves, with a direct effect on motivation and on whether people stay.
What Developer Friendliness Means for Developer Experience
Everything that makes project life easier for developers, testers and others without ever moving into the production system falls under developer friendliness, a hands-on part of developer experience. They aren’t part of the shipped product. They support the people who build it.
Typical examples are automating repetitive tasks or helper interfaces used only internally. If you have ever spent ten minutes every other day going through the same manual steps instead of pressing a button, you know the problem this solves.
Comparing it with user friendliness makes the difference clear. With user friendliness, you think of easy-to-use interfaces, accessibility or fast response times. Those measures are easy to justify, because they visibly end up in the final product. Developer friendliness lacks that visible link, and that is exactly what makes it harder to argue for.
Why Developer Friendliness Keeps Getting Pushed Back
Developer friendliness is often rejected or postponed because its value doesn’t show in the product. Everyone knows the standard objections: we need this feature first, there’s no money left, we don’t have time. Some version of them comes up in almost every project.
In reality, these objections are often justified. Nobody develops in an ideal world where the code comes out perfect, test coverage has no gaps and time doesn’t matter. Sometimes other things really are more important.
But not always. Pushing these measures back across the board ignores two points. First, they do cost time at the start, anywhere from half a day to two or three weeks, but they save time in the long run. Second, the people who use them are happy about them, even if the math only comes out even.
How to Win Management Over to Developer Friendliness
The strongest argument is time. Invest a little now, save considerably more later, and you gain time for other things. Project management gets that math quickly.
The lever is timing. If you propose a measure at the start of the project and plan the effort in deliberately, the long-term savings are easy to justify. And depending on the measure, those savings can be substantial.
A Test Interface That Makes Kafka Manually Testable
One of the most effective measures is an additional interface that exists purely for testing. Lars Luthmann describes it using a leasing system from the automotive industry that consisted of about a dozen microservices. Two of them were part of his subproject: one for contract management with customer data and one for vehicle management.
The main complexity wasn’t inside the services but in the communication between them and how they fit into the business processes. Much of that communication ran over Apache Kafka. For this purpose, you can think of Kafka as a message queue: data is written to a topic, and a consumer reads it.
The problem: writing data to a Kafka topic by hand is cumbersome. The solution was to implement an additional REST interface for each Kafka consumer, meant only for manual testing.
REST was the obvious choice because the tooling is mature and easy to pick up. Back then, everyone on the project used Postman; today Bruno would be an option. There was no barrier to entry. Internally, data coming in through the REST interface was processed exactly as if it had come from the Kafka consumer. The system couldn’t tell the difference.
The effort was small. A colleague spent a good day on the first interface, and every one after that followed the same pattern in about half an hour.
One Good Idea Pays Off across Several Use Cases
A single test interface rarely justifies itself through one benefit alone. The real value shows when you ask what other use cases the same measure covers. That question is exactly what helps when someone sees the benefit but thinks it’s too small.
In the leasing project, the same REST interface served several use cases:
- End-to-end tests: Not planned at first, but needed later. End-to-end tests work with REST directly, without a detour through Kafka topics.
- Team-internal acceptance tests: The business analyst tested on a deployed integration environment that had no write access to the Kafka topics. Through the REST interface, she could still trigger the process at the right point instead of clicking through every neighboring system for ten minutes.
- Cross-system test sessions: In joint conference calls with all subprojects, the process sometimes got stuck in an upstream system. With realistic messages, the team could continue the process from their own system onward.
The last case had the biggest impact. With around 30 people in a session like that, an interface that lets testing start two to four weeks earlier quickly saves many times what it cost.
How a Mock Takes the Sting out of External Dependencies
A mock interface helps when an external service isn’t available during local development and testing. In the same project, part of the communication ran over REST, for example with a service that returned vehicle information such as the manufacturer for a vehicle identification number.
Locally, the team often had access to that service, but not always. Integration environments exist so that people can deploy and try things out. If the service is missing exactly when a process needs its REST call, you’re stuck.
The solution was a mock inside their own service that roughly imitated the external system. No real logic, a bit of randomness, but responses that looked plausible enough. That isn’t enough for large integration tests. It is enough for testing things through locally and for end-to-end tests, because an unavailable external service no longer made the team’s own tests fail.
Easier Testing Leads to Better Quality
The easier something is to test, the more it gets tested. The measures described here target manual and partly automated testing first, but the effect goes further. Less friction in testing means people test more often and more thoroughly. Better quality follows directly.
The same pattern applies to the constant hassle with test data and environments. Preparing test data, setting up environments and tearing them down again always lands on somebody’s desk. Script it properly once, or hide it behind a standard interface, and that recurring burden goes away.
“The best part is, it’s absolutely not rocket science. And it’s not much effort either. All you really need is the ideas.”
(Lars Luthmann)
Where to Find the Ideas
The best candidates for developer friendliness come from the team itself. They are the tasks that make people roll their eyes in the meeting and think “not this crap again.” That’s exactly where it pays to step in.
The side effect goes beyond saved time. Freeing developers, testers and analysts from annoying routine work lifts the mood in the project. And people who enjoy their work are more likely to stay. So developer friendliness is also an argument against staff turnover, not just one for efficiency.
Frequently Asked Questions
How Does Developer Friendliness Differ from User Friendliness?
User friendliness is visibly reflected in the final product: user-friendly interfaces, accessibility, and fast response times. Developer friendliness, on the other hand, never leaves the project environment. Test interfaces, mocks, or automated resets of test environments aren’t part of the final release; they support the people building the product. It’s precisely this lack of direct product relevance that makes it harder to make a case for them.
How much effort do internal tools for development and testing require?
Depending on the measure, the effort ranges from half a day to two to three weeks. This is a one-time investment, and the savings are realized with every use. Even if the net result is roughly zero, there’s still a benefit: those involved are spared the recurring manual labor.
When is the right time to propose such a measure?
At the start of the project. If the effort is deliberately factored into the plan from the beginning, the long-term savings can be clearly justified, rather than having to argue against a full backlog later on. The strongest argument to present to project management is the time factor: invest a little now, save significantly more in the long run, and thereby free up capacity for other tasks.
How can Kafka consumers be tested manually without writing messages directly to a topic?
Through an additional REST interface per consumer, used exclusively for testing. The data is processed internally exactly as if it came from the Kafka consumer; the system cannot distinguish its origin. REST is a natural choice because the tooling is mature and easy to use. In the leasing project described, the first interface took a good day to set up, and each additional one took about half an hour.
Is a test interface worth the effort if it serves only a single purpose?
Rarely. The value comes when the same measure covers multiple use cases. In the leasing project, a REST interface supported end-to-end testing, internal team acceptance testing in an environment without write access to the Kafka topics, and cross-system test runs. If there are about 30 people involved and testing can be done two to four weeks earlier, the effort pays for itself many times over.
When is a simple, homemade mock of a third-party service sufficient?
It’s sufficient for local testing and end-to-end testing, but not for large-scale integration testing. The mock in the leasing project only roughly simulated a third-party system: no real logic, some randomness, but plausible responses. Its purpose was to ensure that an unavailable third-party service would no longer cause our own tests to fail.
Does simpler testing actually lead to better software?
Yes. The less friction there is during testing, the more frequently and thoroughly testing is performed, and this results in better quality. The effect begins with manual and semi-automated testing but extends further: Even preparing test data and setting up and tearing down environments ceases to be a recurring burden once it’s been properly scripted.
How can you tell within a team which task is worth tackling first?
By the reactions during the meeting. The best candidates are the tasks that make people roll their eyes and think, “Not this crap again.” Eliminating such sources of frustration not only saves time but also improves the mood on the project. People who enjoy their work are more likely to stay, so this measure also helps reduce employee turnover.
