People are creatures of habit. That could explain the large amount of custom scripts and processes for automating various parts of our work, especially the repetitive ones, such as deployments. However, that doesn’t explain why they are necessary. Particularly when you take into account that most, if not all, of these issues have already been solved by the community.

Linting, formatting, test runs in multiple environments, changelogs, packaging, and distribution. Is it possible that your team has such specific needs that none of the widely available tools or methodologies can be applied in these scenarios? Do we really need to document every step of the way, just for developers to ignore the documentation? Or stand by obsolete legacy solutions in face of more appropriate ones?

In my experience, these processes and custom tools that implement them represent the limitations that were very real at one time. Perhaps the tool that you want to use for changelog management didn’t exist at the time so your team wrote one? Unfortunately, most of these tools are replaced by better alternatives because they are either not maintained, or no one challenged them enough to continue innovating.

As always, there is a remedy to that. One of the great catalysts is the introduction of a new team member – a fresh pair of eyes that, after a not-so-brief introduction, asks a relatively simple question: “Is there a better way?”.

Until recently, I was in such a situation. Watching endless semi-automatic builds that took more than an hour to complete, various conflicts to resolve, and dozens of different commands to execute. After some tinkering, that was reduced to a couple of minutes with a single command to execute and a minimum amount of documentation covering the process.

Interested in finding out more? Follow the link below and check my blog post that covers that transition process from the perspective of Python packages, but it’s applicable to other programming languages and environments as well.