Can You Foster a Spirit of Experimentation in the Company?

Can Experimentation Be Encouraged in the Workplace?

Software developers are not just tasked with developing simple features. Even when developing a single logic, they must think from the customer’s perspective, experiment, and quickly achieve customer satisfaction. This role requires the mindset of both a businessperson and an engineer. In the past, the focus might have been on quickly creating a single feature, but moving forward, we need to think long-term from a business perspective.

This is why an experimental mindset is necessary. To accurately identify and implement what the customer wants, we need to listen to customer feedback, develop, collect data, and measure satisfaction with short iterations. Paradoxically, a systematic approach is essential for an experimental mindset.

Sometimes, instead of blindly focusing on feature implementation, we need to define whether the problem we are trying to solve is indeed a problem. Good answers come from good questions.

Recently, I voluntarily introduced experimental time into my work schedule. From 9 AM to 12 PM, I quickly tackled important backlogs from the previous day and set aside three hours for experimentation. During this time, I focused on solving problems the company might face in the future. This included changing code conventions, adopting new technologies, or setting up test servers. The focus was on strengthening the current business from a technical perspective rather than the company’s business.

Source of Inspiration

By chance, I saw Chef Choi Hyun-seok on a TV show. Before opening for lunch, he was tasting dishes he had experimented with the previous day. He mentioned that he tests new dishes every day. Watching him experiment with various ingredients, like adding sous-vide egg yolks to ice cream, reminded me of the experimental spirit in software. Just as the fine dining industry thrives on new dishes, software also creates new value in a similar way.

An environment where anything can be freely experimented with maximizes creativity. By applying interesting things and technologies that can contribute to the company in advance, we can prepare for the future while competitors focus on the present.

What I Actually Did

Those who have consistently read my LinkedIn posts know that our company’s backend lacks authentication. It simply accepts a member ID as a parameter and returns information. Accessing a specific API address even exposes hashed passwords. I was honestly shocked when I joined and continuously told the CEO that authentication was necessary… but the CEO didn’t care.

So, I set aside personal experimental time and focused on building an authentication proxy. The setup required JWT login and a proxy to apply authentication to the backend. Naturally, the server needed to be fast. Initially, I built it with Node Express, but due to memory issues, the backend latency was 20000ms. I also faced obstacles during the AWS deployment stage.

So, I switched to Rust. The speed was incredibly fast, but I didn’t know how to build the proxy. Although it was possible, I kept encountering syntax and compile errors, so I thought, “I can’t finish this in time,” and switched to Go.

Since our company has applied Go in production, it was verified in terms of speed and stability. I added a proxy and JWT login to Go. The result..? The backend, which averaged 50ms when accessed directly, was still around 90ms with the proxy, significantly faster than the Node implementation. (I plan to publish a detailed blog post on the process soon.)

When immersed in immediate business value creation or feature development, it’s hard to think long-term. However, no one knows how impactful the features we create will be. That’s why we need to experiment, prove, and improve. If you create something just because it seems like a good idea, it will likely become a feature that no one uses.

After adding authentication, our clients were pleased. They had been inconvenienced by repeatedly logging out and logging in while switching between multiple accounts. By switching the authentication method from session to token, several possibilities emerged. We can now separate environments, and there’s no longer a reason to write PHP-based code.

Fordism

20th-century Fordism is over. With the introduction of AI, there’s no longer a reason to worry about simple repetitive code. Even I have delegated all repetitive UI tasks to AI. My working hours have been reduced by more than half. In the remaining time, I focus on features and technical details necessary for the company and customer satisfaction. Simple publishing has lost its power.

There are still many managers who believe that investing time and manpower will lead to company growth and customer satisfaction, resulting in open wallets. However, as we transition to high-value-added industries, Fordism has completely lost its power. Customers want to respond to a rapidly changing world, and products must evolve in step with those changes. It’s no longer possible to respond by quickly producing and overwhelming competitors.

Ultimately, time for free experimentation and thinking is necessary. Every startup needs time to prepare for the future and explore various possibilities. It’s important to allocate time not only for urgent and important tasks but also for important but not urgent tasks.