Stop The Bleed: With Style!
Table Of Contents
Welcome back. The series so far has introduced the concept of “Stop The Bleed”, an EMS (Emergency Medical Services) mindset, and its potential applications in the field of software development. In the introduction, we explored the ideas that the fast-paced, high-pressure environment of EMS can provide valuable lessons for software developers in terms of efficiency, problem-solving, and prioritization. Some stories were outlined about recognizing that when there is an immediate threat to life, that that threat must be mitigated before any other life saving procedures can be done, can be applied to the health of a codebase.
“Stop the bleed” — a concept that refers to the importance of taking immediate action to address critical issues and prevent further harm. In software development, this means focusing on fixing critical bugs and ensuring that the codebase remains in a stable and functional state before moving on to other areas of concern.
The application of the EMS mindset in software development has the potential to improve the overall quality of code and increase efficiency in the development process. By adopting a “stop the bleed” approach, developers can focus on fixing the most pressing issues first and prevent the accumulation of minor problems that can quickly escalate into more significant, more difficult-to-fix issues.
As the first stop in our journey, we will discuss the importance of code quality.
Code Quality refers to the overall level of excellence and reliability of the code written by a software developer or a team. It encompasses a wide range of factors, including readability, maintainability, performance, security, and compliance with industry standards and best practices. That's all good on paper, but in practice, it can mean many things to many people. Software engineering is filled with intelligent people, and sometimes often, smart differentiate opinions. Sometimes these opinions can be dogmatic and robust. As we describe a “first” step in code quality, as a team of 3, 10, or even as a team of 1, there should be some formalized process on what standards a team should follow. This usually comes in the form of a style guide. These are important first steps that a team should take. They outline what rules should be followed. There should also be a process in the style guide on how to change something. Best practices are constantly evolving and with good reason.
Ten years ago, just about every patient with a hint of back pain would have a c-collar applied and placed on a long backboard to restrict spinal movement. I recall that this happened so many times a day that we would stock a truck with at least four backboards. We never knew how many patients would be at the scene of an accident, so we had to bring a few to handle the suspected spinal injuries. It was in the best interest of the patient, right? I recall going to a fender bender of a job. A school was struck, with minor damage, to the rear fender well. This school bus had thirty pediatric patients on it. Following the protocol, these patients should have been back-boarded and collared because these kids all said they had back pain. A seasoned EMT would know that the kids were just scared, and when you ask a scared kid if something hurts, then say yes. But, the protocol stated that they needed to be back boarded and collared, which was equally terrifying to a child. So, because of the dogmatic protocol, multiple agencies were called out, and most of these kids were placed under spinal restriction. This was not the correct decision, but it was the protocol.
Years later, it was discovered that for the majority of cases, patients rarely needed this level of spinal restriction, and it contributed to backboard injuries. How could this happen? The need to be “cleared” by a doctor before the board was removed meant patients would often be strapped down for hours in the Emergency department before anyone could see them. This thought process is changing as hospitals and doctors use data to determine that most people do not need this restriction.
Thankfully, these kids did not have to suffer through that and were removed from the boards quickly.
Today, the use of backboards is a lost art. I can’t remember the last time someone met the criteria for spinal immobilization. Newer EMTs, with less than five years on the job, can count how many patients meet the new guidelines. Guidelines are in place to help make decisions when there is ambiguity. I have seen many debates over even the simplest of changes throughout my career.
Code quality is important for a number of reasons:
- Improved reliability: High-quality code is more reliable, less prone to bugs and crashes, and generally more robust. This leads to a better user experience and fewer support requests. Also improved Developer Experience, which I will dive into in a later blog post.
- Increased efficiency: Code that is well-written, organized, and easy to understand can be maintained and updated more efficiently, saving time and resources in the long run.
- Better collaboration: When code is of high quality, it is easier for multiple developers to work on the same codebase, reducing the risk of conflicts and facilitating collaboration.
- Faster development: High-quality code is often faster and more efficient, allowing developers to implement new features and make changes to the codebase quickly.
- Improved security: Code that follows best practices and is written with security in mind is less vulnerable to attack and data breaches, protecting both the users of the software and the reputation of the development team.
The “Stop the Bleed” mindset can be applied to code quality, and this is undoubtedly an important concept to bear in mind. When you enter a new codebase, and it feels like the “Wild Wild West” when you are reading and writing code, there’s likely some “bleeding.” As engineers, we are always learning something new, and it is our responsibility to ensure that the codebase is of the highest quality. Improving the codebase’s health by enforcing quality standards is not easy, but ensuring that the code is up to the best standards is necessary.
The obvious step is to address the quality of the code itself. However, it is also important to take a step back and look at the bigger picture. The “bleeding” in this scenario is not the code; it is the developers. If you are the only one subscribed to the idea that the code should be written in a specific way, without a style guide, then you are setting yourself up for failure. It is important to ensure that all the developers in the team understand the importance of code quality and that they are all on the same page when it comes to standards and expectations. This will help to ensure that the codebase is as healthy as possible and that everyone is contributing in a positive way. The first steps here are to build a style guide with a team. You don’t have to start from scratch, there are many templated and opinionated style guides to choose from. From this initial meeting, set up a way to contribute to this style guide. I cannot stress enough the importance of getting the style guide agreed upon, and then have everyone follow the standards. When a team sets up a process, and then does not follow that process, what can happed is much worse.
Conversations about the use of semi-colons, variable names, and the number of lines in a method are often seen in pull request reviews, which can significantly slow the PR cycle time. Without a style guide to refer to, the same style violations are often repeated, leading to a lack of team cohesion and time wasted, and frustrating for all involved. Pull requests should not be used as a forum to debate the merits of one style over another; instead, if there is no style guide in place, these conversations should take place in a more appropriate setting and should result in a shared style guide that all team members are aware of and adhere to. This will create a sense of consistency while allowing for flexibility and individual preferences. Individual preferences are also necessary. This is why this is called a style guide, not style laws. Guides are meant to assist the developer in following practices that the team put in place, but this is software, and there are cases in which the guide can be deferred from, with good reason. A software developer should always be able to defend their position on why they made a a decision to not follow the style guide.
*Side tip: During an interview at a new company, ask to see their style guides and inquire about their quality standards. This is a great way to gain insight into how a team or company creates and enforces standards.
Once you have a style guide in place, the next step is to shift the nagging to a bot. This is a great way to automate the process of enforcing the rules that we have all agreed on. In the ruby world, we have several tools to help us enforce the rules we are all trying to follow. Rubocop, a ruby gem that runs static analysis, is a great tool to use, as it is able to detect any violations of the style guide, and alert the team to any syntax errors or other issues. Additionally, Rubocop can be used as a great teaching tool, allowing developers to learn best practices, and ensuring that everyone is writing code that adheres to the same standards. By using Rubocop, we can not only streamline the process of enforcing the rules, but also ensure that everyone is writing code that is consistent, readable and of high quality. Brakeman is a powerful security tool that offers an effective approach to improving codebase security. It can detect vulnerabilities in applications written in Ruby on Rails, and provide actionable insights to help identify and fix security flaws. Brakeman can also track changes over time to ensure the codebase remains secure and that any new changes don’t introduce security issues. It also provides detailed reports for developers to review and address any security concerns. Brakeman is an excellent asset for any Ruby on Rails developer looking to ensure their codebase is secure. These are but 2 examples directly related to the ruby world, but not limited to it. Every programming language has built-in tools to assist engineers in solving problems without manually going through the painstaking process. These processes have already been solved and can be automated, ultimately saving time and resources. It is important to note here that Code Climate’s “Quality” product is one such tool that I have been using for years, even prior to starting my job at the company. It enables you to perform all these checks as part of a pull request, thus reducing the need for debugging and striving for a higher code quality. Moreover, you can even get an automated overview of the entire codebase, enabling you to understand the structure and any potential issues that may arise from it.
By utilizing Code Climate’s “Quality” product, engineers can save time and resources by automating the process of debugging and striving for higher code quality. Additionally, the product provides an automated overview of the entire codebase in order to gain further insight into the structure and any potential issues. This can be especially useful when working with a large and unfamiliar codebase. Furthermore, the product is easy to integrate into existing workflows, making it a great choice for any development team. Static analysis is one of those tools I wish I could reverse engineer to an EMS Chart, highlighting areas where an EMT should have performed one action over another. Sadly, this is still a manual process, however, I would like to experiment with some AI tools in the future to improve this process.
The “Stop the Bleed” mindset, derived from the world of Emergency Medical Services, is a valuable concept for software developers. In this post, we highlight the need for team buy-in and then discuss how to set up and follow style guides. By focusing on fixing critical issues and maintaining the stability and functionality of the codebase, developers can improve the overall quality of their code and increase efficiency in the development process. Code quality is important for a number of reasons, including improved reliability, increased efficiency, better collaboration, faster development, and improved security.
A key aspect is the use of a style guide, which outlines the standards and expectations for the team and helps ensure consistency and readability in the codebase. Additionally, automating the process of enforcing these standards through tools such as Rubocop, Brakeman, and Code Climate’s “Quality” product can save time and resources while improving code quality.
Hey everyone! In our next series, we’ll be diving into the topic of “Developer Experience”, and how the “Stop the Bleed” mindset can help make it even better. Don’t miss out on the latest stories and info on software development and the EMS mindset!
