Creating a good working atmosphere

Developer friendliness refers to measures that are not implemented in the production system but are used exclusively to make day-to-day work easier for developers, testers and other project participants. Typical examples are test interfaces, mock services and automated resets of test environments. The short-term effort pays off in the form of long-term time savings and better software quality.

Key Takeaways

• Developer-friendliness measures cost time in the short term, but pay for themselves by permanently speeding up repetitive tasks and thus freeing up more capacity in the long term.
• Implementing a REST interface as a test input for Kafka-Consumer was a piece of cake after the first day and then only took half an hour per interface.
• Simplifying manual testing automatically improves quality because tests are performed more frequently and more smoothly.
• An internal mock service for external REST dependencies protects local development and automated testing from external system of systems failures.
• When a development team reduces frustration points, the mood in the project improves and this has a direct impact on the motivation and commitment of those involved.

What developer friendliness means

Developer friendliness comprises measures that make the day-to-day project work of developers, testers and other stakeholders more pleasant without migrating into the production system. They are not part of the delivered product. They support the people who build the product.

Typical examples are the automation of repetitive tasks or auxiliary interfaces that are only used internally. Anyone who performs the same actions for ten minutes every two days instead of pressing a button knows the problem that is being solved here.

A comparison with user friendliness makes the difference clear. When we think of user friendliness, we think of easy-to-use interfaces, accessibility or fast response times. Such measures are easy to justify because they are visible in the end product. With developer friendliness, this visible reference is missing, and this is precisely what makes the argument more difficult.

Why developer friendliness often falls behind

Developer Friendliness is often rejected or postponed because its benefits are not visible in the product. Everyone knows the standard objections: we need this feature first, we have no money to spare, we have no time. They crop up in variations in almost every project.

These objections often have authorization in reality. Nobody develops in an ideal world where code is perfect, test coverage is seamless and time is not an issue. Sometimes other things are actually more important.

But not always. Anyone who pushes these measures to the back of the queue is forgetting two points. Firstly, although they initially cost time, from half a day to two or three weeks, they save time in the long term. Secondly, the people who use them are happy even if the calculation only works out to plus minus zero.

How to enforce developer friendliness with management

The strongest argument is the time factor. If you invest a little time in the short term and save significantly more in the long term, you gain time for other things. A project manager quickly understands this calculation.

The leverage lies in the early stage. If you propose a measure at the start of the project and consciously plan the effort, the long-term savings can be clearly justified. And these savings can be considerable, depending on the measure.

A test interface that makes Kafka manually testable

One of the most effective measures is an additional interface that is used exclusively for testing. Lars Luthmann describes this using a leasing system from the automotive industry, which passed around a dozen microservices. Two of these were in his sub-project: one service for contract management with customer data and one for vehicle management.

The main complexity was not inside the services, but in the communication and integration into the business processes. A large part of this communication ran via Apache Kafka. In simple terms, Kafka can be understood as a message queue: Data is written to a topic and a consumer reads it.

The problem: manually writing data to a Kafka topic is cumbersome. The solution was to implement an additional REST interface for each Kafka consumer, which was only intended for manual testing.

REST was chosen because the tooling is mature and low-threshold. At the time, everyone in the project used Postman; today, Bruno would be an option. There was no barrier to entry. The data from the REST interface was processed internally exactly as if it came from the Kafka consumer. The system could not distinguish the origin.

The effort was minimal. A colleague took a good day to set up the first interface, and each subsequent one followed a standard procedure in around half an hour.

A good idea pays off over several use cases

A single test interface is rarely justified by a single benefit. The real value becomes apparent when you ask what other use cases the same measure covers. It is precisely this question that helps if someone sees the benefit but finds it too small.

In the leasing project, several use cases were created from the same REST interface:

• End-to-end testing: Originally not planned, but later needed. End-to-end testing works directly with REST, without going through Kafka topics.
• Internal team acceptance testing: The business analyst was testing on a deployed integration environment where there was no write access to the Kafka topics. Using the REST interface, she was still able to trigger the process in the right place instead of spending ten minutes clicking through all the neighboring systems.
• Cross-system test appointments: In joint telephone conferences with all sub-projects, the process sometimes came to a standstill in an upstream system. With realistic messages, the process could be continued from the own system.

The last case had the greatest leverage. With around 30 people in such a meeting, an interface that enables testing two to four weeks earlier quickly saves many times the effort.

How a mock defuses external dependencies

A mock interface helps when a third-party service is not available during local development and testing. In the same project, part of the communication ran via REST, for example to a service that returned vehicle information such as the manufacturer from a vehicle identification number.

This service was often accessible locally, but not always. Integration environments are there so that something can be deployed and tested. If the service is missing exactly when a process needs its REST call, you are stuck.

The solution was a mock in our own service that roughly replicated the external system. No real logic, a bit of chance, but answers that looked plausible enough. That’s not enough for large-scale integration testing. It is enough for local testing and end-to-end testing, because an unavailable third-party service meant that our own tests no longer failed.

Simpler testing produces better quality

The easier it is to test something, the more testing is done. The measures described are initially aimed at manual and semi-automated testing, but their effect goes further. Those who have less friction when testing test more frequently and more thoroughly. This directly results in better quality.

The same pattern can be seen with test data and environments. Preparing test data, setting up environments and clearing them again always ends up with someone. Once cleanly scripted or hidden behind a standardized interface, this recurring burden is eliminated.

The best thing about it is that it’s not rocket science at all. And it doesn’t take much effort either. All you really need are the ideas. Lars Luthmann

Where to find the ideas

The best candidates for developer friendliness come from the team itself. These are the tasks that make people roll their eyes in meetings and think “not this crap again”. This is exactly where the intervention pays off.

The side effect goes beyond saving time. Freeing developers, testers and analysts from annoying routine tasks creates a better atmosphere in the project. And people who enjoy their work are more likely to stay. Team member friendliness is therefore also an argument against fluctuation, not just one for efficiency.