In my last post I talked about my background as both a manufacturing engineer and a software engineer. In this next post I want to talk about what I think manufacturing engineers can learn from software engineers and software engineering in general.

I’m honestly not sure how many manufacturing engineers end up becoming software engineers and vice versa. What I can say from experience is that for a pair of vocations with “engineer” in the title and a lot in common they don’t seem to mix much. This is a real shame, because the tools that have been honed and perfected over time in both areas would be, in my opinion, of massive benefit to each other.

So here is a post where I discuss one of the tools and techniques from the world of software engineering that would happily carry over to manufacturing. The great news for any manufacturing engineers reading this is git is either free or dirt cheap. So, why not give it a go?

I’m going to assume the reader of this article knows nothing about any of git and include some definitions along the way. Apologies if you know this and it seems a little demeaning. If you see a word you don’t understand, check the glossary at the bottom of this page.

What Git?

The first tool on our list is humble git. It’s the de-facto source code control system used in all types of coding to track changes and maintain version control over codebases. According to Statista 84% of software engineers use some form of version control system as part of their daily work. It’s so ubiquitous that its one of those things “you just need to know” to get a job as a software engineer.

Git was originally created by the people that created and maintain the Linux kernel. As time has gone on various companies have created web services and code repositories that are a wrapper around git. Possibly the most famous of these is GitHub

How is it used in software engineering?

The best way to think about this is to imagine that production planning Excel document you’ve got on a shared drive at work. When somebody opens it up they lock the file for editing, which means when you want to do something in there it says read-only. This inevitably means you have to run around the office shouting about trying to find out who’s got the document open. You spend ten minutes looking only to find out it’s Gary, and he’s gone for a cuppa so you’re stuck for another 20 minutes while the kettle boils.

This problem occurs in software engineering too. In a reasonable sized software engineering company it’s not uncommon to have a team of 40 developers working on the same codebase at the same time. The business wouldn’t be very efficient if each developer had to wait for the other one to finish so they could start their work would it?

In short, Git allows teams of almost any size (Google, for example, has a single repo for literally everything) to work in the same code at the same time. But that’s not all. Git is a full suite of version control software. This means you can look at any given line of code and see when it was added, when it was last changed and by whom, and the full history of changes before that.

Users can review changes before they are merged and highlight areas they think should be improved. Once you’ve agreed on the changes and everyone is happy, you can merge the changes into the main codebase. This is called a pull request.

How does it work?

I could write a whole series of blog posts about the ins and outs of git (people definitely already have, and I’m far from an expert). But I’ll try to give a brief overview of the flow of operations so you can get a feel for how it works. While reading, try to think about how this could be used to support a change management process or for documentation version control in manufacturing.

Let’s follow a typical workflow using this blog (which I store on GitHub) as an example. I’m going to make some changes to my previous post, and we can follow the changes through the process.

Note: I’m using a combination of GitHub and the PyCharm IDE to do this, but there are many other ways to do it.

Step 1 - Viewing the Repository

Step 2 - Creating a Branch

I’ve decided I want to make some changes to my previous blog post. So the first thing I’m going to do is create a local branch of the document to work on. Doing so means that I can make my changes in isolation without affecting the ‘official’ copy of the document. It also means that somebody else can make changes in this document and elsewhere at the same time. Git will make sure that one persons changes do not overwrite the other and both sets of changes make it into the master copy if desired.

I create a new branch and give it a recognisable name. I check out the branch, so I can begin working.

Step 3 - Making Changes

Step 4 - Pushing Changes

I want to send my changes to GitHub (where the master copy is stored) so that I can get my changes reviewed. Here we can see the commit message I made earlier and a total list of all changed files.

Step 5 - Creating a Pull Request

Step 6 - Reviewing Changes

The great thing about GitHub is that other members of my team can now go and review changes. They can easily see what lines have changed and what things looked like before. They can also comment on the changes and suggest improvements. This discussion and history is saved forever in the GitHub log and can be referred to at any time.

Here we can see which lines have changed, so we can focus on the changes in the context of the document as a whole.

Sorry about the rather silly conversation with myself here. You’ll have to pretend this is two different people talking.

Step 7 - Approval

Before we can merge our changes we need to get an approval. You can set up GitHub to require a certain number of approvals before changes can be merged. This is useful for ensuring that changes are reviewed by multiple people and that the changes are of a high quality.

Here we can see that another user can add comments, approve the changes or request that changes be made before approval. We’ll choose to approve.

The approval and comments are again stored forever in the history of the git repository. So you can look back at any given change and view the discussion that took place around it. You can also see who approved it and when.

Step 8 - Merging Changes

Now out changes have been approved we can merge them into the master branch. This means our changes become part of the main copy of the document and are available to everybody.

Step 9 - Tracing Changes

When I pull the latest changes into my editor. I can see for each line of the document who made the last change and when. It’s easy to trace these changes back to a specific commit and pull request if we want to see the discussion and larger context.

And there we have it, we’ve followed the process of maintaining a version history of documentation using git. This process can be completed as many times as you like. It’s also infinitely parallelisable, so multiple people can be working on changes in different areas at the same time, all feeding into the master copy of the document.

How could it be used in manufacturing?

My hope is that by this point you can see how this process could easily be applied to a manufacturing environment. However, I’ll give a few examples in case it wasn’t clear.

Change Management

Every engineering environment I’ve worked in has some method or another for controlling changes to processes in a facility. These processes normally have a three letter acronym and revolve around typing up a word document which is then sent to a committee for approval. You might be required to show evidence of process capability or a risk assessment.

I feel that adopting this process would achieve the following benefits over such a system:

• This process effortlessly captures all the discussion that happens around a change. This is incredibly useful for future reference and for understanding why a change was made. It can also facilitate lessons learned and continuous improvement events by providing a record of what happened and why.
• By keeping everything electronic we can easily search for changes and remove the scenario where an engineer inevitably leaves and takes the original with them. Want the excel copy of the original Gauge R&R study? No problem, just search for it in the git history.
• The approval process can be completed in a fraction of the time. No more waiting for the weekly change committee to meet or running around the factory wit your paper copy to get signatures. Just send a link to the pull request and wait for the approval to come in.

Documentation Version Control

Documentation and version control is incredibly important in all aspects of manufacturing. If you have an out of date copy of a work instruction on the shop floor that’s a minor mark in an ISO9001, PPAP or TS audit.

In one of the places I’ve worked we used to employ a person full time as a “Documentation Controller”. I’ve built a lightweight system around git in two weeks for a company that allowed shop floor staff to view the latest copy of any work instruction electronically at the touch of a button. This completely removed the need for a full time documentation controller and saved the company a lot of money, while removing the risk of audit failure.

NC Programs

CNC programs are arguably the easiest sell for this process. They’re already stored as plain text files and git is a perfect tool for managing changes to them. No more milling_program_v4_FINAL_FINAL_2023.txt files. You can even use git as a DNC system to push the latest version of a program to a machine.

Conclusion

I hope this article has given you a good idea of how git can be used in a manufacturing environment. The good news is the complete suite of tools I’ve shown here are completely free to use. If you’d like to chat about setting up a documentation repository using git then feel free to get in touch. You can email me at hello@jakesaunders.dev.

Glossary