01 - Revert to last known working state
Today I want to explore some of the ideas of version control system and how they can be applied to project management in general. If you are not familiar with version control, don't despair; I'll explain it quickly.
What is a version control system
If you are writing, be it computer programs, a novel, or a scientific paper, it is useful to keep track of the changes you introduce. You could create files with names like 'my-thesis-v1.doc', 'my-thesis-rev1-v2.doc', etc. or you can make use of programs that allow you to keep track of the changes automatically.
Either by using a program or a self-defined system, you can know what happened at every stage. You can tell that you added or removed a paragraph. If you are developing software, you can see if a bug was solved or introduced into the program. And this has fabulous applications because it allows you to see the entire history of changes and identify those that may have generated issues.
Revert to a known working state
Many people used to develop software know that they can revert to a computer program's past state. If something stops working as expected, you can go back to a previous version working fine, and then you'll have time to fix the issue. Software, in general, can be updated and distributed at virtually zero marginal cost, which is a significant advantage compared to other types of products.
However, the same ideas that software engineers use can be applied to other types of projects, especially if there are no users yet. It is what happened to me recently, in the project I've been working on for the last two years. We are building a new device to characterize nanoparticles. It is a hardware project, starting from scratch: design, manufacturing, functionality, etc.
After over a year, I hit a roadblock. Things were not working. There were too many variables, options, choices that accumulated over time and pushed the product towards a state that was not addressing our customers' problems. It was when the idea of reverting to the last known working state appeared.
Fortunately, I had been tracking the decisions made by systematically taking notes of every meeting and documenting the available choices. I could see up to which point things were progressing in the proper direction, and when we started to depart, very slowly, from where we wanted to be. All this information allowed me to identify the moment to which I liked the product to revert.
It is not possible to go back in time
Ideally, we would like to go back in time and tell our past self to take a different path. However, we have to acknowledge that this is not only impossible but also resources are finite. We can't just drop what we did and start over. Money is an entropic force that flows only in one direction before we can deliver a product.
Therefore, we must embrace the things we learned and did during this path that went wrong. We can't scratch it from the record, but we can use it as a stepping stone. In my case, there was a clear element that was very wrong. I focused too early on the user experience before even having a working prototype. This simple issue branched into many different choices that piled up and brought us to the status we wanted to revert.
Once I managed to identify the force that pushed the wrong decisions, I could also determine how it could have been different. Perhaps 80% of the things I had done would have been the same, but that remaining 20% was a dead end. Of course, changing 20% of a product is much more realistic than starting from scratch. Moreover, without the user experience pressure, I could iterate on the parts that need to be changed much more quickly.
How to be able to revert back
We live in a world that moves too fast, with smart people advising us to break things in the process. However, being resilient is a matter of dedication, of taking the time. In my case, the only thing that allowed me to identify the critical moments of the history was that I had been documenting the process. My drive to document came partly because of my formation, partly because I wanted to have the material ready to learn for future projects.
Systematically taking down meeting minutes, writing my thoughts, noting who thinks what, and the choices we had in front that we chose not to follow. There is, of course, no one-size-fits-all for this, but the more introspection you do (and can do in the future), the better it will be. Each one will have to choose the tools and strategies that best serve them. Some people have fantastic memory. Some (like me) need to write down and, more importantly, need to see it to build upon.
Have you ever needed to revert?
If you have ever been in a situation where you needed to revert to a past state, I would love to hear how you did it. I want to learn what allowed you to identify the moment to which you wanted to return and, more importantly, how did it feel.
These are the other notes that link to this one.