Tiqqe People

The importance of code ownership

In Today’s post I’m going to speak about why owning code or, more in general owning a part of a project, has a lot of benefits, but I won’t do it by giving a correct definition of what code ownership is or describing the several ways you can use it: I will do it by sharing my personal experience. 



When I graduated some years ago, my dream was becoming a digital nomad. Going around the world with my computer, working from anywhere and whenever I wanted, felt it was the best way of doing this job. With the passing years and a lot of new experiences made, I realized that I preferred to settle down somewhere so I abandoned the idea of being a nomad but not the idea of freedom in doing this profession.  

When Sweden was hit hard by Covid-19 and we started to work from home, I started to realize or actually to see clearly how much time I spend working in a week and much impact that has on my free time, on my personal life. I started to feel I was in a cage and to think that after all, I was not learning as much as I wished.
At that time we were working at the migration of an old system to AWS. My tasks were a bit everywhere and they were not so interesting or challenging. I started to look at the clock and to wait for my eight hours passing. I was sad and without motivation. I was in the middle of a crisis. 

Stuff completely changed when we decided to split the whole migration in single features migration and I got the ownership of one of them. I became the owner of a part of the project and suddenly I had the responsibility of going to production with that. My life at work was completely twisted: I started to plan, schedule meetings to get requirements, discuss with the client, make decisions about code and architecture, make sure to share knowledge about the feature with my team, make sure to properly test the implementation and make sure to release the feature. My productivity just skyrocketed, as well as my level of satisfaction at work.

Finally I was working on a project that I felt was mine. I was part of something I would have been in also in my free time. I was learning and improving my skills exponentially. Finally I was feeling like I was an independent developer and not only an employee. I got my freedom back.

Therefore, code ownership is not only about owning a module, a function or a file for “agile” reasons but it is also and above all, something that every developer that needs more freedom should ask for. I think it is something that is more important and useful for the developers than for the companies, the clients or for the project itself.

Last week we released the feature on the first pilots and I cannot be happier for that. 

AWS

The introduction of Site Reliability Engineering (SRE)

The introduction of Site Reliability Engineering (SRE) teams in the structure of an organization, is becoming more and more popular in the IT industry and in the DevOps domains.
Let’s discover in this article the reason for SRE popularity and what are the differences and the common points between DevOps and SRE. 


In the last two decades we have witnessed a huge transformation in the way of building and delivering software. The Agile culture first and the DevOps revolution later, have transformed the structure of the tech organizations and they can be seen as a de facto standard in the IT industry.

As everyone knows, IT is a constantly evolving sector and recently we are seeing an increasing popularity of Site Reliability Engineering discipline, especially in the DevOps domains. But what is SRE? And what are the differences and the common points between SRE and DevOps? 

DevOps

DevOps culture has contributed to tearing down the wall between software development and the software operation, providing a set of ideas and practices that has led several benefits:

  • Better collaboration and communication between the parts;
  • Shorter release cycles;
  • Faster innovation;
  • Better systems reliability;
  • Reduced IT costs;
  • Higher software delivery performance.

Even though this sounds amazing, there are still quite a lot of companies that struggle with bringing the DevOps culture in their organization. The reason for this is that DevOps is an ideology and not a methodology or technology, which means it doesn’t say anything about how to successfully implement a good DevOps strategy. 

SRE 

Site Reliability Engineering (SRE) is a discipline that was born at Google in early 2000s to reduce the gap between software development and operations and that was completely independent by the DevOps movement. SRE uses software engineering approaches to solve operational problems.
SRE teams have main focus on:

  • Reliability;
  • Automation.

Let’s deepen these aspects.

Reliability

One of the main goals of the SRE is making and keeping systems up and running “no matter what”. In order to achieve this, it is important to keep in mind that failures and faults can happen. SRE discipline embraces them by focusing on:

  • observability;
  • system performance;
  • High availability (HA);
  • emergency response and disaster recovery; 
  • incidents management;
  • Learning from the past problems;
  • disaster mitigation and prevention.

Automation

Automating all the activities that are traditionally performed manually is another of the main goals of SRE.
Automation and software engineering are used to solve operational problems. 

Automation plays a fundamental role in SRE: it allows us to get rid of human errors present in the processes and the activities that regard the system. One could argue that automation introduces bugs in the system anyway and well, that is true but there is one big difference: one can test automated processes but cannot test processes that involve human activities. 

DevOps vs. SRE

As we have understood, both DevOps culture and SRE discipline aim to reduce the gap between software development and operations. Below we summarize them, describing their common goal first and where they differ the most. 

class SRE implements DevOps

As mentioned earlier DevOps doesn’t say anything about how to successfully bring the culture in the organization since it is an ideology. On the other hand, SRE can be seen as implementation of the DevOps philosophy. 
In fact, even though the origins of SRE are completely independent from DevOps, and the discipline provides additional practices that are not part of DevOps, SRE implements DevOps ideas.

Responsibility and Code ownership

SRE can be considered the next stage of DevOps because of the focus on code ownership: the SRE engineer accepts the responsibility of owning the code they develop, in production. A bit different from DevOps where the responsibilities are shared to achieve a shorter release cycle and to improve the collaborations.

Conclusions

The introduction of Site Reliability Engineering (SRE) teams in the structure of an organization, is becoming more and more popular in the IT industry and in the DevOps domains. 
The reason for its popularity can be found in the benefits that the discipline brings: 

  • Better collaboration and communication between the parts;
  • Shorter release cycles;
  • Faster innovation;
  • Better systems reliability;
  • Reduced IT costs;
  • Higher software delivery performance;
  • Reducing incidents in production;
  • Code ownership;
  • Automation of the processes;

As you could notice some of these benefits are exactly the same that you will experience bringing DevOps in your organization.

SRE can be considered an implementation of DevOps culture that has the goal of making and keeping services reliable.