I used to underestimate the use of precise technical terms in order to describe my technical world. Instead of taking the time to find the correct terminology, I would just explain what is it that I wanted to do. For example, I would say, “I want the system to cope with erroneous input" instead of using the term "robustness."
Fast forward to a few years later. One of the first things I noticed in one of the companies I worked for was the flow of conversations. It really seemed like everybody "spoke the same language." When someone said something, the other person would immediately understand their meaning and intent, and vise versa, which produced very productive sessions. I decided to explore how effective communication works using a well-defined common terminology.
A common code release looks like this:
System before change consists of three components
System after change: One component is replaced with an improved component.
If something goes wrong and and a rollback is possible, the rollback should replace the new production code with the old production code (replace C2’ with C2). The rollback plan usually means:
1. Revert the current release by committing the opposite diff to the project’s version control.
2. Deploy the above change to production.
3. Restart the project’s services to apply the new code.
4. Once the rollback process is completed, additional fixes may be needed such as repairing damaged data.
Every developer knows that it does not matter if you work in Agile, Scrum, Lean, Kanban or Waterfall methodologies, when it comes to software projects — something always gets out of control. Requirements tend to change frequently, time estimations are a wild guess, coordination with other teams is not perfect, and every person in the release chain can easily fail the deployment. How can software engineers deliver under these conditions?
During my work as a backend team leader, I got to manage a few of the complexed software projects of the company. Most projects were challenging technically since we had to replace backend components of a live system which handles millions of agents but they were no less challenging socially, since I needed the cooperation of many people in the organization in order to push the code to production.