The Adventure of a Hidden Feature

A few weeks ago, we came out of a process we had been going through for nearly a year. We wrote about our experiences during that transition week here. In this article, we will talk about how we managed both the development and the release system during this one-year process. 

First of all, we should mention that the modules we developed are big enough to be separate applications on their own because they are part of a super-app we’ve been building for our Germany-based client. Throughout this one-year process, we developed two modules to track employee hours during the construction period starting from the work plan all the way to the result. We also developed a file-folder system with new features enabling users to store all kinds of files. And since we would be presenting the existing system with a new UI/UX, we also transferred the data our client created in the past to the new system.

As a dedicated team of 13 people applying Scaled Scrum to the project, it’s clear that we cannot complete and deliver these applications all at once. Because when we consider the feature set, development, and test procedures that are needed, the process becomes a very lengthy one. And - of course - our internal discussions, QA processes, and meetings with our stakeholders to deliver the features in the most optimal way are also included in this process.

So, how can we incorporate a feature/module that takes a long time to develop into our application? There are a few methods that come to mind. Some are good, and some are bad. Without further ado, let’s run through the list:

1. Not releasing the application at all before the new features are complete. 
2. Developing new features separately from the main branch.
3. Developing new features in the main branch but turning them on and off with environment variables.
4. Using the feature flag system.

There are probably more ways to do this, but let's stick to these examples. Based on our experiences, I think the first two are wrong, the third is acceptable, and the last one is the most useful. Because for a feature that takes a whole year to develop, it would be unfortunate if we couldn't develop the app at all, or even debug it. Needless to say, every software has different needs. So at first, we tried option 3 for a long time and then switched to option 4 when our needs changed. 

If you have a product that you need to develop actively, there are small features in addition to long-term ones as well. There are always some problems you have to solve and things you need to improve. Therefore, not releasing the application for long periods of time is a huge disadvantage for both the development and the product team. 

At Atolye15, we use LaunchDarkly for our feature toggling products. With this product, we meet our feature toggling needs both in Frontend and Backend. The features we control with the help of flags can be turned on and off within the application at runtime without going through any build process. We can also customize the flags for a specific user or user group and perform A/B tests.

‍In long-term development, features are always available as codes in the production environment. When the time comes, we first present the features to our QA engineers, then to product owners, and lastly to beta group users with a single click. After the parties involved are sure the work is correct, we release the feature to all users. With the convenience of an application functioning in this type of runtime, we can toggle any feature at any time as quickly as possible. And we can achieve this without encountering any obstacles such as downtime, development difficulties, and so on. 

To put it short, feature toggling is just one part of a large development ecosystem we have created internally. In order to ensure it’s effective, we have fast-build pipelines in our toolset, a continuous integration and review process that protect the developer and the product, a trunk-based development git flow that keeps our development momentum constant, and a massive process that allows us to deploy to production in a manner of minutes. When each of these pieces comes together, we obtain a sustainable infrastructure, and our team continues to work with the same happiness and productivity.

If you want to be a part of a team that develops products in this way, feel free to take a look at our Career page and apply for the position you want!