Software Configuration In A Developer's Life!

A developer gets introduced to a feature on one of the ticketing system, be it JIRA, Trello, etc. and starts working on it, when it gets assigned to him/her either during the sprint or when the feature reaches the top of kanban board (big fan of kanban).

As soon as, the feature is picked for development, the most basic questions start running in his/her mind:

1. What should be the data structure used?
2. What algorithm should be used?
3. How should I make is user/client-friendly?
4. How should I make it robust or as my German friend calls it "Bullet Proof" or "Battle-tested"?
5. How should I make it maintenance-free or future proof?
6. How should I make this feature easily extendible or dynamic?

So the solution to questions 1 to 4 is a bit straightforward in most cases as there are standards defined or if the system is already in place, we tend to build on top of it.

Now comes the tricky part where the developer needs to run his imagination to design it so that we can make it future proof and easy to extend. Of course, the choice of data structure and existing architecture helps make the decision, but every new feature has its own issues of backward compatibilities, robustness, and maintenance.

This is where most developers introduce an application configuration for a feature, which in most cases, helps in achieving the solution for the last 2 questions.

Let's see how:

For the sake of understanding, let's take an example feature request and the most common one: "A Sign-Up form."

In a user-centric app, the sign-up form keeps changing, let's add three more conditions to our requirement:

• Sign up forms of fields should be region-based.
• Sign up form fields should be role-based.
• Sign up form should have multitenant support.

First of all, developers don't get these conditions together to plan and provision for all conditional requirements. These conditions are always incremental and keep growing as and when the app progresses.

For the above scenario, the approach taken by companies is usually to seek the support of 3rd party sign-up forms or develop them in house using application configuration, which is different from infrastructure configurations.

And this is how one of the standard directories structures gets developed, where our sign-up fields are saved in JSON or YAML file type.

And soon, with multi-region support, directory structure changes to:

Now, any change in any of the configuration, developers needs to:

• Change in the codebase
• Create a Merge Request/pull request on Github/Gitlab
• Get it reviewed and tested
• The last step is deployment, with or without downtime

Imagine updating these configuration 100s of times, which will be 4x steps to be completed to make it production.

This is where Nonfig saves the day. Now let's reduce 4x steps back to 1x to make these changes in production. Nonfig enables developers to bring all their configurations in a centralized place, where the whole team can collaborate and control the behavior of the product.