Simplicity In Startups
layout: post title: Simplicity in Start-ups description: > Make things simple categories: [posts] tags: [simplicity, startups] author: Levi Malott —————
We focus on three concerns that are important in most software systems: Reliability The system should continue to work correctly (performing correct function at desired level of performance) even in the face of adversity (faults or human errors). Scalability As the system grows (in data volume, traffic volume, or complexity), there should be reasonable ways of dealing with that growth Maintainability Over time, many different people will work on the system (engineering and operations, both maintaining current behavior and adapting the system to new use cases), and they should all be able to work on it productively. On Maintainability We can and should design software in such a way that it will hopefully minimize pain during maintenance, and thus avoid creating legacy software ourselves. To this end, we will pay particular attention to three design principles for software systems: Operability Make it easy for operations teams to keep the system running smoothly. Simplicity Make it easy for new engineers to understand the system, by removing as much complexity as possible from the system. Evolvability Make it easy for engineers to make changes to the system in the future, adapting it for unanticipated use cases as requirements change.
―Martin Kleppman, Designing Data-Intensive Applications
The axis of scalability to worry about in start-ups is complexity, not data volume or traffic.
As a consequence, I recommend we don’t focus on scalability right now.
First, we need to care about reliability (correctness and performance) as we have a responsibility to
the people using our products (whether internal or external). If complexity is our growth constraint, then we should focus on much more on maintainability, namely simplicity and evolvability.
I offer this prioritization: (1) reliability (it works and has adequate performance), (2) maintainability (simple, operable, and evolvable), then (3) scalability.
Future scalability shouldn’t come at the cost of present day reliability and maintainability. Once something is reliable and maintainable, then should we attack scalability. Not before. Ideally, we monitor performance and utilization and know when to focus on scalability by deeply understanding our systems and bottlenecks. If we do that then we can observe leading indicators to unlock investment rather than surprise load failures. We don’t ignore scalability. We create a stable system, put the right monitoring in place, and review overtime. Then you can proactively invest in making the parts scalable that present themselves as bottlenecks in the system.
When you are building in a startup, there’s more business or value risk than technology risk in most cases. You want to deliver as fast as possible to validate hypotheses and reduce those risks first. The worst feeling is investing an enormous amount of time into building the wrong thing. Wrong meaning it didn’t provide customer value.
It’s really, really easy to focus on building the technology and miss the bigger context of who actually cares on the other side. Especially in fast growing teams. It takes a lot of discipline to say “no” to ourselves as craftspeople and learners. BUT so important. We want to innovate and push novel ideas forward. Often we love the experience of coding. It’s much harder to question the purpose of that code in terms of value it’s providing but those are the right discussions to be having. Choose Boring Technology hits the nail on the head and is still relevant today, if not more. Just pick a language, pick a database, pick a hosting platform and go. Don’t look back, don’t re-question it until it’s causing pain.
If you or your engineers are worried about scale and breaking down, write a plan. If this things is so successful, what will break and what are the leading indicators? What would you need to do differently to support that success? Write it down somewhere and review periodically. This is a healthy practice to adopt regarding operational excellence. You won’t be blindsided unless you somehow land millions of people on your product instantly. In that case, congratulations because you have a successful start-up my friend.