After having a lengthy conversation with one of my colleagues on the topic of why people often disregard guardrails in his organization, a particular question came to my mind. Towards the end of our discussion, I asked my colleague what keeps cars between the guardrails in the real world. He replied, somewhat unsure of where I was going with this, “Drivers?” I quickly countered, “Guardrails themselves! I don’t think you have guardrails if you only have some guidelines that you want to enforce.” Interestingly enough, on the same day, I had another conversation with someone else who suggested making the golden path mandatory in their enterprise. This sparked the idea for me to write a blog post comparing these concepts.
Guidelines are a set of recommended best practices or rules that help to ensure consistency, quality, and efficiency in a particular process or activity. And I emphasize on the word recommended! While guidelines are important to follow, they are typically flexible and can be adapted to suit the needs of a particular project or team.
In the context of software development, guidelines may include coding standards, design principles, testing practices, and other recommended approaches for developing high-quality software. Guidelines provide a framework for developers to follow, and can help to prevent errors, increase maintainability, and promote collaboration among team members.
Examples of guidelines in software development
- Coding standards: Guidelines for how code should be written, formatted, and documented. This can include rules around naming conventions, indentation, comments, and file structure.
- Design principles: Guidelines for how software should be architected and designed. This can include principles like separation of concerns, single responsibility, and open-closed principles.
- Testing practices: Guidelines for how software should be tested to ensure quality and reliability. This can include practices like unit testing, integration testing, and automated testing.
- Security guidelines: Guidelines for how software should be secured to protect against vulnerabilities and attacks. This can include practices like encryption, authentication, and authorization.
- Performance guidelines: Guidelines for how software should be optimized for performance. This can include practices like caching, indexing, and load balancing.
- Documentation guidelines: Guidelines for how software should be documented to ensure clarity and ease of use. This can include guidelines for writing user manuals, API documentation, and developer documentation.
I noticed that guardrails are often confused with guidelines, but they are actually distinct concepts. While guidelines provide recommendations for best practices in software development, guardrails are designed to enforce some of these formerly recommendations, by providing automated or semi-automated checks and controls. Guardrails are built on top of guidelines, but they go a step further by making some of those recommendations compulsory.
In software development, guardrails are often used to enforce best practices and prevent errors before they occur. Guardrails can be implemented at various stages of the software development lifecycle, such as during the build, test, and deployment phases.
Guardrails typically operate in the background and provide feedback to developers on potential issues or violations of guidelines. This allows developers to quickly identify and fix problems, ensuring that software is developed to a high standard of quality and consistency. Unlike guidelines, guardrails are typically more rigid and less flexible, as they are designed to prevent errors and enforce compliance with established policies.
To illustrate this, consider a security guideline that recommends not committing database passwords to source code. In such a case, a guardrail can be established to enforce this guideline and prevent developers from sidestepping it. For example, the guardrail may be designed to deny a push to source control if a password is committed. By doing so, the guardrail ensures that the security guideline is followed consistently and helps to prevent potential security breaches.
Examples of guardrails in software development
- Automated code reviews: A guardrail that uses automated tools to scan code and identify issues such as security vulnerabilities, code smells, and design violations. The tool may prevent a commit or a merge request if certain issues are detected.
- Code quality thresholds: A guardrail that establishes a minimum threshold of code quality (ex. maintainability, readability, performance, etc.) that must be met before code is allowed to be merged into the codebase. (ex. you can use SonarQube Community for your pull requests)
- Deployment automation: A guardrail that ensures that only approved changes are deployed to production environments. This can include automated testing and approval workflows that verify that the code changes are safe and do not introduce issues into the system.
- Compliance checks: A guardrail that checks that code adheres to regulatory requirements (ex. HIPAA, GDPR, etc.) and internal policies. This can include checks on data privacy, access controls, and other compliance-related issues.
- Resource limits: A guardrail that limits the amount of resources (ex. CPU, memory, disk space, etc.) that an application can use. This can help prevent performance issues, crashes, and other problems that may result from resource exhaustion.
In software development, the term “golden path” refers to the optimal or ideal path to achieve a goal. The concept is similar to the golden path in the novel “Children of Dune”, or a maybe more familiar one, in the movie “Avengers: Endgame,” where Dr. Strange explores all possible outcomes and identifies the optimal path towards achieving the Avengers’ goal (to defeat Thanos and save the universe).
Spotify defines golden path as the opinionated and supported way to build something. Golden Paths are a concept in platform engineering where the platform offers pre-architected and supported approaches to building and deploying software. By following a Golden Path, a team can get a supported road to production without having to learn all the details of the technology used to create that road. This accelerates onboarding of new team members and applications and injects best practices learned from past experiences.
A Golden Path usually include a repository template to get started with, a pipeline to build and push resulting artifacts to production, monitoring (logs, traces, metrics and alerts) capability, and fairly easy to understand “getting started” and “how to” documents. This can be done done through a developer portal.
Golden Paths should be optional and not the only way things are done to allow and foster innovation. The abstractions created by Golden Paths should be transparent so that if a developer wants to understand what happens behind the curtains, they can easily do so.
Unlike guidelines and guardrails, Golden Path is a more prescriptive approach that offers a more limited range of options. It is designed to ensure that developers follow a proven methodology and helps to create a more standardized software development process across the organization. Golden path is your futured guideline but you should never create guardrails that limits everything to golden path.
In conclusion, guidelines, guardrails, and golden path are all useful concepts in software development. Guidelines are recommended best practices that provide a framework for developers to follow and help to prevent errors, increase maintainability, and promote collaboration. Guardrails, on the other hand, enforce the some of guidelines by providing automated or semi-automated checks and controls, which prevent errors from occurring, and ensure compliance with established policies. Golden path, in contrast, is a prescriptive approach that provides a limited range of options, ensuring that developers follow a proven methodology and create high-quality software.
In software development, it is crucial to strike a balance between the flexibility provided by guidelines and the rigidity of guardrails and golden paths. Developers need to be given the freedom to innovate and adapt to project-specific needs while ensuring that the software is developed to a high standard of quality and consistency. A well-implemented combination of guidelines, guardrails, and golden paths can ensure that developers have the necessary tools to create high-quality software while minimizing errors and maintaining consistency across projects.
Furthermore, it is essential to keep in mind that guidelines, guardrails, and golden paths are not static concepts but rather should evolve over time. With new technologies and methodologies emerging, these concepts should be revisited and revised to reflect the latest best practices and industry standards. By continually adapting these concepts, teams can stay at the forefront of software development and deliver high-quality software that meets the evolving needs of their users.