The ideal software form
Last updated
Was this helpful?
Last updated
Was this helpful?
"Our codebase is pretty depressing," Tommy said, his voice filled with frustration. "All we have are Balls of Mud, big or small. We start every project with great expectations that this one will be different, but they all end up as the same mess eventually. Will we ever create the ideal software of our dreams?" "Aha, I highly doubt it. It's like Plato's idea of Form: we can get closer to it, but we can never truly reach it," I laughed. "The second law of thermodynamics states that the entropy of an isolated system can only increase without extra energy input. Software is also a system constrained by the laws of physics." "So, we're doomed?" Tommy seemed depressed. "Not necessarily. Our goal in software development is to create systems that solve real problems. Usefulness is the number one measure of a software's worthiness. But quality matters too. Without quality, software systems become wasteful, ugly, fragile, unreliable, and unsustainable," I explained. "So, how do we know if software is close to the 'ideal form'?" Tommy asked. "Well, there are many ways to define 'ideal' software. Here are some common architectural traits that come to mind:
Fast feedback loop from a code change to customer value. Agile development, Continuous Integration/Continuous Deployment (CI/CD), Minimum Viable Product (MVP), Incremental Release, Feature Flags, and A/B testing all center around fast feedback loops to collect customer feedback.
A strong, portable, purely functional Domain Logic Core that is decoupled from infrastructure code. This is from the Domain Driven Development (DDD) movement: the domain model should reflect the business vocabulary; the domain services should map to customer-facing use cases that carry the majority of business rules; the aggregates and bounded contexts define the boundaries of software modules; the repository and unit of work abstraction decouple the domain services from the data persistence layer. If your Domain Logic Core's code is 80+% of your total codebase, you have a pretty good software.
Can you cover 80+% of your codebase in unit tests? Can your unit tests serve as documentation for your Domain Logic? Can you complete your automated tests in 30 minutes reliably on your CI/CD pipeline? This is part of the Test Driven Development (TDD) movement.
Do you have a clean separation of Control Plane and Data Plane?
Do you have a clean separation of synchronous API layer and asynchronous workflow layer that run on different servers? Do you leverage event-driven workflows?
Do you treat your logs and metrics as a gold mine for operational excellence and business intelligence, using real-time streaming and big data technologies?
Do you have Command and Query Responsibility Separation (CQRS)? The domain model for mutation and view are rarely compatible."
"Maybe we should rewrite everything in Rust; isn't that the silver bullet?" Tommy joked. "Right, now you're really dreaming!"