Blake Wight

Blake Wight

How to make big projects developable

What I would do as Chief Dictator of Engineering

How to make big projects developable

I have had the opportunity lately of being a contributor on a lot of projects at my current place of employment. I have run into snags trying to get codebases running, connecting to databases, testing things locally, etc... Running into this problem one time is enough to be annoyed, but generally not that bad because you resolve the issue once, and then it is smooth sailing from then on. When you run into these same types of problems many times, it starts to become unbearable.

Think about how much time is wasted with these large projects. It adds up. In my frustration, I have been mulling over the rules I would institute if I were the Chief Dictator of Engineering.

  1. Projects must have all documentation for getting the project running locally, dependencies, how to deploy, any scripts that you can run, and anything else you might need to know included in the README.

  2. The steps to get the project running should be at most 3 steps. Anything more is too much. In my mind 1 is too little because docker-compose up might need some kind of configuration that allows the local machine to connect to other resources, or for dependencies.

  3. All back-end codebases are run locally in docker. This means fewer steps to get the project running. Almost shouldn't be a separate point, because it enables the previous.

  4. Any two codebases should be able to run at the same time on one machine. The configurations of each shouldn't conflict with each other. For example .bashrc exports, .aws/credentials default profile etc...

  5. This one is a little bit more ambiguous, but getting the local environment up and running, testing code changes should also be extremely easy. Less than 3 steps. Most of the time this should be a non-issue, but sometimes code runs in different locations like as a Shopify app, or in an iframe. Steps should be included in the README of course.

  6. Anything that you need to test should work, or be mocked in non-prod environments. Most companies pay for some software to help with email, analytics, SMS, auth, etc... If they can be implemented cost-free and simply in non-prod environments, they should just work as normal, except maybe with non-prod identifiers. Those services that would incur an additional cost for testing should be mocked. Either as code running on a simple server or as hard-coded values.

  7. Small codebases. This is ambiguous, but once a product starts to break out into more than one codebase, go all the way. Break apart the monolith, but do it right. Throw it behind an API gateway, and move logic into other codebases and phase out the monolith. Get codebases that are only maintained by a few people that can quickly educate others on how to make changes when needed.

The end goal: Any developer with only a few tools installed on a new machine (like git and docker) should be able to clone any repo and be up and running within an hour with no problems.

Slow is smooth and smooth is fast. I believe these would make development smooth.

What am I missing that you would add as CTO Chief Dictator of Engineering? What about remove?

Photo by Fernando Hernandez on Unsplash

#software-engineering
 
Share this