My principles for building software
Context Link to heading
(Inspirations: My programming beliefs as of July 2024 and My Principles for Building Software)
Here are my personal thoughts about building software. I’m constantly updating and improving this page.
Table of Contents Link to heading
Principles Link to heading
Maintainability Link to heading
- People (developers) time are more expensive than machine time (at least until the AGI).
Simplicity Link to heading
- “Simplicity is the ultimate sophistication.”
Automated testing Link to heading
- It’s a must, although I believe it is already a consensus in the industry.
Scalability/Performance Link to heading
- Computers are fast
- Don’t try to optimize to solve a problem you don’t have
- “Premature optimization is the root of all evil” Donald Knuth
- Data-driven optimizations. You need observability to detect bottlenecks and optimize based on it.
- Optimize based on the number of users.
- Optimizations Should be driven by the SLAs/SLOs defined by the business.
- People (developers) time are more expensive than machine time (at least until the AGI).
- You system is probably IO bound. If so, you don’t need a CPU/memory optimized languages.
Monolith first. Microservices need justification. Link to heading
- Microservices add way too much complexity.
- If your team doesn’t know how to separate concerns in a monolith, they won’t know how to do it in microservices. Unless you are centralizing the separation decisions, but in this case you are not solving the problem.
- Microservices are about team topologies and scaling systems with different types of bounds
- References
- https://x.com/milan_milanovic/status/1722252645438484810?s=46
- The Majestic Monolith
- Meme: Microservices orchestration complexity
- How to recover from microservices
- MonolithFirst
- Monoliths are good enough for almost everything. Microservices need justification.
- Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%
- Stack Overflow Architecture
- The Majestic Monolith
- What Powers Instagram: Hundreds of Instances, Dozens of Technologies
- Why you should build a (modular) monolith first?
HTML first. SPAs need justification. Link to heading
- Backend should be the only source of application state.
- References
SQL first. Others need justification. Link to heading
- SQLite or PostgreSQL is probably all you need.
Business first Link to heading
- All code must serve the business.
- Technical decisions must be driven by the business.
PaaS first. Building a platform needs justification. Link to heading
- Do NOT start building your own platform - PaaS will be better built and cheaper than hiring DevOps and building internally.
- People (Ops) time are more expensive than machine time (at least until the AGI).
- When to build a platform internally?
- When the cost of building and maintaining is smaller than paying a PaaS
- Or when you have a specific use case not supported by PaaS (uncommon)
- References
🗣️ “Platform engineering will ultimately solve the central problem of cooperation between software developers and operators.”
No it won’t. It will make “DevOps/Infrastructure” teams reinventing the wheel by building their own Heroku version.
- Meme “Using Kubernetes to deploy your uncle’s bakery website”: https://x.com/o_gabsferreira/status/1242140290443546625?s=46
Devs Ownership Link to heading
- Dev team must own the application from end to end (code, infra, testing, deployment, monitoring, etc.)
- Devs should work with stakeholders to gather requirements. Only juniors can afford to want well-defined tasks. It’s the job of senior devs to talk to stakeholders, understand requirements, prioritize, define scope, etc.
To think/write about Link to heading
- Containers are for external services. The application should run locally.
- Prefer pure functions and immutable data - improves testability, predictability, etc.
- Security
- Documentation
- No build
- Solve things by building it, not only thinking about. You won’t be able to solve everything in your mind; Some stuff needs to be be built to show up the issues; You should focus on easy changing, not doing it right the at first time.
- Typing dynamic languages is a mistake