Do best practices really matter?

🌈 Abstract

The article discusses the author's re-examination of commonly accepted "best practices" in software engineering, and argues that blindly following such practices may not always lead to the most effective or valuable outcomes for a business. The author shares their experiences at Stripe, where they found that the company's approach of prioritizing "shipping" over strict adherence to design patterns and extensive testing was more effective in delivering value to the business.

🙋 Q&A

[01] Questioning Best Practices

1. What are some of the common "best practices" that the author was taught early in their career?

• Using design patterns like the factory pattern and avoiding singletons
• Writing more tests to cover edge cases
• Refactoring code to maintain high code quality

2. How did the author's perspective on these best practices change over time?

• The author found that the tests they wrote were often flaky and didn't catch the bugs they expected
• Refactoring often introduced new bugs and took longer than anticipated
• Many of the "best practices" felt like "cargo cult programming" - done because they were thought to be right, not because they actually helped

3. What was the author's key revelation after joining Stripe?

• Stripe's codebase used a more procedural, command-based structure rather than heavy OOP
• This structure was easy to understand, maintain, and test, challenging the author's assumptions about OOP being necessary for maintainable code

[02] Maintainable Code

1. What are the key traits of maintainable code according to the author?

• Readable and easy to understand
• Discoverable in how it's intended to be used
• Predictable with no unexpected side effects
• Limited blast radius when changes are made
• Debuggable when issues arise
• Testable with easy-to-mock dependencies

2. How does the command-based structure used at Stripe align with these traits of maintainable code?

• The command structure encapsulates business logic in a simple, easy-to-understand way
• There's no complex OOP hierarchy to navigate
• Testing is straightforward with clear inputs and outputs

[03] Testing Pragmatically

1. What are the author's key points about when testing is worthwhile?

• The Pareto principle applies - after covering the happy path and a few error cases, the ROI of additional tests diminishes
• Tests should focus on business logic, not just boilerplate code setup
• Consider the cost of the code failing - if it's low, extensive testing may not be necessary

2. What does the author recommend regarding integration and end-to-end (E2E) tests?

• Integration and E2E tests are more valuable than extensive unit tests
• They can test more in less code, although they are slower and more brittle
• Investing in good integration and E2E tests is one of the highest ROI testing strategies

[04] Avoiding Premature Optimization

1. How does the author view the common advice about "premature optimization"?

• This advice often gets lost when it comes to system design, leading to over-engineering
• Modern hardware is incredibly fast, and data volumes are often not as large as anticipated
• Most scaling issues are caused by bugs, not the actual feature design

2. What does the author suggest as a better approach to system design?

• Ship features quickly and iterate based on user feedback
• If a feature becomes successful, optimize performance later
• Many businesses could survive on a simple Docker container hosted on a cheap VPS instance

[05] Delivering Value

1. What is the author's key point about the purpose of writing code?

• The goal is not to write the "best" code that impresses other engineers
• The goal is to deliver the most value to the business as quickly as possible

2. How does the author recommend balancing code quality and speed of delivery?

• Understand when it's worth investing in tests, refactoring, design patterns, etc., and when it's not
• Aim for "good enough" code that can be shipped quickly, rather than striving for perfection
• Focus on the best use of time and resources to benefit the business