When to start using a new tool - pre v1 or not

Ryan YatesConsultant

Just a person in their 30's doing things in Tech & trying to break the stigma's around talking about Mental Health
    DevOps PowerShell Tooling Opinions   DevOps PowerShell Tooling Opinions  Comments

This post will be a nice short one that allows you to understand when I take a dependency on a tool in any development of production code and is inspired by this question by Waldek Mastykarzn on twitter

So I thought that I best blog this for future reference on the reasons for when I personally choose to use tools like this

I’m hesitant of using pre v0.5 in anything that I deem to be going to need to be supported by my/other orgs teams as so many things start & then don’t continue to be updated or supported

At least a v0.5 is a clear indication that there is desire for it to continue & a v1 more so

For POC’s (Proof Of Concepts) before v0.5 is completely fine for code I am handing to another team to support when I

  1. Know the team/individual behind the tool/library.
    1. This helps as I have a trusted point of contact for it which is a huge bonus
  2. See there is a roadmap.
    1. This helps as you can see where the team behind it are thinking of new features.
    2. This shows longevity and health of the project.
  3. See it gets coverage in it’s own or a wider set of tools community calls so that there’s ample room for questions to be raised by me and others.
    1. This helps as it can be questioned verbally on a recorded call for future reference.
  4. How busy a repo is in terms of commits / issues / prs (if public).
    1. This lets me know if it is just the team behind the product or there are other contributors too.
  5. How regular releases are.
    1. Again this shows to me what the maturity of the project is like and how well the DevOps processes are behind this project.
    2. This is also something that due to 1) would allow me to decide if it’s a project that may not have it implemented but will do shortly, as it’s costly to implement a build and release pipeline if you may change underlying tech stack for the project, examples being moving from a PowerShell to C# binary module or from .Net to a go tool.
  6. What the build & release pipeline looks like (again if repo is public).
    1. Ideally this should show what actions/tasks the repo uses, if any are custom scripts (if so how readable they are to me/others)
    2. Also allows for me/others to suggest improvements too! Win-Win!

These are the core things for me at least that help me decide on taking a dependency in tooling that is used as part of any part of the ALM (Application Lifecycle Management) process (which Is just what DevOps/Platform Engineering is based one, which is another post that I will go into and will release sometime in the future.) Obviously there are other things that I take into consideration, including the complexity of the project and supportability of it if I needed to Inner Source it or add extensions to it. Having worked in a few teams that have extended a public tool with features that could have been added to the public tool instead of via an additional library to internally support, this is something I try and advise against, and instead recommend that this it done on public forks so can be merged back in to the project, where possible.

Hope this helps anyone reading, and please feel free to leave some comments to me about this. Oh and thanks to Waldek for asking the question!