Code culture & corporates
Marc Andreessen said once “Software is eating the world.” and it’s true, we can not imagine anything in our lives without finding it’s based on some software! Starting from our phones, cars, homes & work, everything is code.
Today, the world’s largest bookseller, Amazon, is a software company, the largest video service by the number of subscribers is a software company, Netflix, and the dominant music companies are software companies, too: Apple’s iTunes, Spotify, and Pandora
Writing, Reading & understanding code became a must for everyone, even if he’s not a programmer! If you’re doing a digital transformation, & I’m sure you are! you’re dealing with code too!
But not everyone is succeeding by coding and using code, coding needs to be crafted! you need to have some best practices to be sure you’re helping your company and not the opposite. we're talking about software craft or code culture! But what’s a code culture?
What is code culture?
Companies are looking for performance, they are trying to attract the best talents and get accompanied by the best consulting companies to achieve this and have the best culture that helps on this. if you ask C-level persons what’s the most important ingredient to perform they will say: “having the right culture in the company, an enterprise culture that enhances people to better collaborate, communicate and help each other reach excellence and the result wanted”. But what is a culture/enterprise culture?
In literature I have found that Dr. Ron Westrum has done good work to define culture, He is an Emeritus Professor of Sociology at Eastern Michigan University. He has done a study about the flow of information and its relation to organizational culture and performance. Westrum’s research included human factors in system safety, particularly in the context of accidents in technological domains such as aviation and healthcare
In his research, he developed the following typology of organizational cultures :
Besides, according to research by DevOps Research and Assessment (DORA), an organizational culture that is high trust and emphasizes information flow is predictive of software delivery performance and organizational performance in technology. it’s similar to what Westrum found! He noted that such a culture influences the way information flows through an organization. Westrum provides three characteristics of good information:
- It provides answers to the questions that the receiver needs to be answered.
- It is timely.
- It is presented in such a way that the receiver can use it effectively.
For Westrum, culture can be defined as follows :
DORA research shows us also that a high-trust, generative culture predicts software delivery and organizational performance in technology. this is confirmed by a large two-year study at Google, we found that high-performing teams need a culture of trust and psychological safety, meaningful work, and clarity. In the 2019 State of DevOps Report further analysis shows that a culture of psychological safety is predictive of software delivery performance, organizational performance, and productivity.
Both DORA research & Westrum studies show us it’s about people interactions more than members! also another study from Google (2015) answers this question: What made teams effective? Who is on the team matters less than how team members interact & structure their work.
The way to change culture is not to first change how people think, but instead to start by changing how people behave – what they do.Jhon Shook - 2010
When we talk about software, having a good culture starts essentially by having good technical practices/behaviors, in the end, it’s all about the code ;). That's why we will focus on this next.
Continuous delivery
Continuous delivery (CD) is a set of capabilities that enable us to get changes of all kinds — features, configuration changes, bug fixes, experiments — into production or the hands of users safely, quickly, and sustainably. It will help reach the clean code/architecture culture you want.
When the Agile Manifesto was published (2001), Extreme Programming (XP) was one of the most popular Agile practices. It describes a set of technical practices, like test-driven development (TDD) and continuous integration, lately, these practices and others were called Continous Delivery (Humble & Farley 2010).
In the last decade, many Agile adoptions did not pay the necessary attention to technical practices. Based on “Accelerate”(*) research, these technical practices are vital to achieving a good and positive culture!
Next, we will discuss some of the principles and foundations of continuous delivery and how they impact organizational culture.
CD Principles
In this chapter, we will see five principles of Continuous Delivery that help companies achieve excellence and good code culture!
Build Quality in
In software, quality is not negotiable! we need to care about it from the beginning, teams that leave quality checks at the end, have a big problem: the cost will be expensive to solve issues!
The third of W. Edwards Deming’s fourteen points for management states, “Cease dependence on inspection to achieve quality.” Eliminate the need for inspection on a mass basis by building quality into the product in the first place” (Deming 2000). In continuous delivery, we invest in building a culture supported by tools and people where we can detect any issues quickly so that they can be fixed straight away when they are cheap to detect and resolve.”
Dr. W. Edwards Deming’s outlook on quality was simple but radical. He asserted that organizations that focused on improving quality would automatically reduce costs while those that focused on reducing cost would automatically reduce quality and increase costs as a result.
Martin Fowler has discussed this point in the past, He stated that having a low internal quality can help you deliver fast at the beginning, but you will slow down in a few weeks compared to having high internal quality!
Work in small batches
Organizations tend to plan work in big chunks — whether building new products or services or investing in organizational change. By splitting work up into much smaller chunks that deliver measurable business outcomes quickly for a small part of our target market, we get essential feedback on the work we are doing so that we can course correct it. Even though working in small chunks adds some overhead, it reaps enormous rewards by allowing us to avoid work that delivers zero or negative value for our organizations
This principle is also Lean Startup’s one, Eric Ries explains in his book that working in small batches is fundamental in any successful entity or organization!
By adopting any Agile framework, you will split work into small steps/batches. Scrum does this when we split specifications in a backlog of user stories, or delivery into steps called sprints. This is essential to have quick feedback so we can adjust.
Computers perform repetitive tasks, people solve problems
Building and delivering products can be very time-consuming, teams have to do some repetitive tasks like compiling & building the software, deploying services, or monitoring it. These kinds of tasks can generate errors and team frustration! Humans hate to repeat things in general!
it’s better to invest some time to optimize and automate this kind of task so we can free up people to solve real problems that have a higher value.
Continuous improvement
High-performing teams are never satisfied, they always try to be better! It’s important to make continuous improvements a habit in the team’s daily work!
Agile frameworks give us some tools to implement continuous improvement, like retrospective: when the team is gathered to review their work and how to improve it and remove impediments.
Everyone is responsible
Based on Ron Westrum's research, in bureaucratic organizations teams tend to focus on departmental goals rather than organizational goals: development focuses on throughput, testing on quality, and operations on stability. But these are just system-level objectives and need collaboration between all stakeholders and entities to achieve organizational goals.
at first, Agile come to help developers to collaborate with business owners, later DevOps came to do the same between developers and operations.
CD Foundations
Principals are good, but not enough! we need to make sure we have some Continuous Delivery foundations so they will facilitate getting the right outcomes
Version control
Version control, also known as source control, is the practice of tracking and managing changes to software code. Version control systems are software tools that help software teams manage changes to source code over time (*)
Version control has been adopted by the majority of teams in every company, That’s a good starting, but it’s mainly used for product code sources. DORA research shows that using version control for configuration and environment helps high-performance teams to achieve excellent outcomes.
It should be possible to provision your environments and build, test, and deploy your software in a fully automated fashion purely from information stored in version control.
Continuous integration
Many software development teams are used to developing features on branches for days or even weeks. Integrating all these branches requires significant time and rework. this is opposite to the principle of “work in small batches”. Teams need to integrate their work frequently into trunk/main branch, this integration will trigger unit tests to check no regression is added. Any failure detected must be fixed immediately by the team.
Trunk-based development
Developers think “Git flow” or feature-branch is the best branching strategy, but researchers found that developing off trunk/master rather than on long-lived feature branches was correlated with higher delivery performance.
Teams that did well had fewer than three active branches at any time, their branches had very short lifetimes (less than a day) before being merged into Trunk and never had “code freeze” or stabilization periods.
The “Github flow” workflow can be helpful when developing open-source projects, the contributors are not working full time! but in corporate projects teams are dedicated.
Test automation
The tests are part of the delivered code, it is not a step at the end of the development cycle. Testing is essential, it must be done throughout the development process. Unit tests should be run after each commit to get quick feedback.
Developers should be able to run all automated tests on their workstations to triage and fix defects. Testers should be performing exploratory testing continuously against the latest builds to come out of CI.
Automatic tests are like an insurance policy for the team. Developers can engage in improvement work or refactoring of existing code if a set of automatic tests covers the code.
Shifting left on security
When teams “shift left” on information security, i.e. when they integrate it into the software delivery process instead of making it a separate phase that takes place downstream of the development process, it has a positive impact on their ability to practice continuous delivery. This, in turn, has a positive impact on delivery performance.
DevSecOps & Rugged DevOps are two ways to implement a “shift left on security”. We recommend adding security control in your DevOps pipeline, like static & dynamic checks, dependency audits, or other security steps. But that’s not enough, it’s important to add security in the specs too, to involve the cybersecurity team during the project’s architecture scoping to avoid any major changes afterward.
Loosely coupled architecture
Architecture is so important for high-performing teams, But using the latest microservices architecture deployed on containers is no guarantee of higher performance if you ignore the most important characteristics: Deployability and Testability!
To have better performance, teams must choose loosely coupled architectures with deployable and testable components. if you have systems that are difficult to test, you will struggle to create other services around them!
Architectural approaches that enable this strategy include the use of bounded contexts and APIs as a way to decouple large domains into smaller, more loosely coupled units, and the use of test and virtualization/containers as a way to test services or components in isolation.
Empowered teams
In many companies architects focus on technology or tools even if they’re not working with them, generally, it’s a source of frustration between them and engineers. This approach is based on some reasons, like :
- Reducing IT complexity
- Managing skills and be sure we have the necessary ones to manage technologies in place
- Having purchasing power with vendors
- Managing technology licensing and support contracts
But this is not the right approach. Tool choice is an important part of technical work. When the team can decide on which tools to use to deliver, they will be more performant. This isn’t surprising. The professionals who develop and deliver software and run complex infrastructures make these tool choices based on what is best for completing their work and supporting their users. When we said tools it contains languages and frameworks also.
The role of the architects' team is not to define these tools, but to help engineers to achieve the Organization's goals.
That said, there is room for standardization, especially around infrastructure and architecture configuration. Cybersecurity teams can define some pre-approved list of toolchains, so we minimize attack risk.
CD impact
Implementing Continuous Delivery influences organizational culture, but how?
These practices will help developers to detect problems when they occur, they will have time and resources to invest in and fix them. With CD, developers have responsibility for global outcomes, this has a positive influence on the team interactions and collaboration, aka team’s culture!
When teams adopt CD practices, studies showed they have these outcomes too :
- Strong identification with the organization you work for.
- Higher level of software delivery practices and performance.
- Lower failure rate
- performance-oriented culture.
Generally, CD helps you have less deployment pain and less burnout, which are the most pathologies a team culture can have. It confirms also what Agile experts said :
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely” (Beck et al. 2001).
Continuous Delivery helps you also to do less rework, which is a big problem for the team. Rework means generally bad quality in the first place! it’s also a source of frustration for the team members. In The Visible Ops Handbook, unplanned work is described as the difference between “paying attention to the low fuel warning light on an automobile versus running out of gas on the highway” (Behr et al. 2004). In the first case, the organization works in a planned manner, but in the second one, it’s urgent. all the engineers must stop their work and try to fix the problem.
Some organizational culture traps to avoid
Organizational cultures with high information flow often encounter the following pitfalls:
- Completely ignoring the importance of culture and treating technical work only as a technological and process challenge.
- Focusing only on local team cultures and not reaching out to also understand how team cultures interact with the larger organizational culture.
- Not having enough support, or appropriate support, from leaders and managers for the necessary culture change and transformation.
- Ignore or punish bad news. It is best to understand that failures are inevitable in complex systems and treat them as opportunities for improvement and learning.
- Not encourage novelty. Admiral Grace Hopper, the famous computer pioneer and inventor of the compiler, once said, “The most dangerous phrase in the language is ‘we’ve always done it this way.” Allowing and encouraging teams to experiment and try new things makes work better.
