This week I started helping a small startup evaluate and streamline their prototype application. Every time I start one of these projects, I’m struck in the face by how many common anti-patterns I see repeated on practically every project.

Today I want to talk about the over-use of configuration.

Here’s an (anonymized) snippet of the configuration for the application I’m working on (extracted from the docker-compose configuration):

      - S3_LOCAL_PATH=./static/
      - EMAIL_TEMPLATE=./static/notifications/email.yml
      - SMS_TEMPLATE=./static/notifications/email.json
      - PUSH_TEMPLATE=./static/notifications/email.json
      - FIREBASE_PRIVATE_KEY_PATH=./firebase.json
      - PUSH_NOTIFICATIONS_PATH=./static/notifications/push/push.json

This is just silly.

Literally none of these variables should exist.

Why?

This application is executed in one of two modes:

1. From a Docker container
2. In the local development path

Providing file paths to programs that execute from within Docker is almost by definition redundant. The whole idea of Docker is to package a complete application.

And in many cases, such as this one, development needs are no different. If there were some need to specify an alternate path, it would probably be enough to have a single configuration variable pointing to the top-level path.

Needless to say, I’ll be ripping out these configuration variables and replacing them with constants. This will reduce complexity both in the program itself, as well as in the configuration and depoyment. Win-win for Dev and Ops!