🎓 What `MVP` actually means; Horizontal vs. Vertical scaling
What `MVP` Actually Means
I was having a conversation with one of my favorite managers in recent years, Brandon, at my last full-time job.
We were discussing how to deliver value both individually and as a team, and how to do it more quickly.
He shared a wonderful article that helped me redefine MVP – Minimum Viable Product – as a focus on the value instead of the product.
Instead of rewriting the same idea and analogy, please read Making sense of MVP by Henrik Kniberg. Keep reading here for a brief TL;DR and my thoughts on how a senior engineer applies this mindset.
TL;DR:
An MVP is not a chunk of “big bang” delivery, where you don’t deliver customers anything until it’s 100% complete.
If the intention is to deliver a car, an MVP is not releasing a wheel, then a frame, then a body… Engineering teams in agile environments tend to fall into this pattern as we plan for sprints.
An MVP is better thought of as a Minimum Valuable Product, or as Henrik puts it, the earliest testable product. (“Testable” means can be tested by users, not automated testing for code.)
The sooner you deliver any kind of value for your customer, the sooner you can get feedback on the direction you’re heading. Learn, iterate, repeat. If you get too far into a big bang delivery and you’re wrong about something, you lost a lot of time and effort.
How a Senior applies this mindset
Figure out your skateboard.
Identify an MVP that delivers value by breaking up your work into fully-functioning pieces. Do you need to build a feature that includes both front- and back-end layers? Don’t deliver one on its own – that’s the same as delivering the wheel of a car. Find a vertical slice that includes a minimum valuable and usable portion of all layers to deliver first.
Think in terms of MVPs when prioritizing and planning.
When working through your backlog, think about delivering MVPs of the features first to help determine what has the most impact (priority), limit scope creep, and provide timetables for planning.
MVPs help you learn.
In my last issue we discussed Making (Reasonably) Good Decisions Quickly, and one way to do that is to use prototyping to learn and validate an idea:
Use prototyping, testing, and automation. Building prototypes and conducting quick tests can provide immediate feedback and inform decisions, especially when choosing between different technical approaches or designs.
Foster a learning and iterative culture.
Encourage a mindset where failures are seen as opportunities to learn and pivot, rather than setbacks. Use MVPs and iteration to develop this resilience, especially when building new products.
MVPs enable communication.
Keep stakeholders informed with regular updates that focus on progress, challenges, and decisions. Guide junior team members through the MVP process, teaching them to balance speed, quality, and user focus in their work.
You become a Senior Engineer by focusing on the value you deliver your team, your organization, and your customers. Every MVP that delivers value, even a small amount, increases your impact and shortens your path to Senior. 💪🏼
Vertical vs. Horizontal Scaling
Scaling refers to increasing the ability of a system or application to handle increasing amounts of data, traffic, or load, without compromising performance or security.
Scaling comes in many forms, from application code changes to significant infrastructure additions. Today we’re focusing on two types of server infrastructure scaling: vertical and horizontal.
Vertical Scaling (Scaling Up)
Vertical scaling involves increasing the power of a single server or resource. This could mean adding more CPUs, RAM, or storage to the existing hardware.
Pros
Simplicity – It's often easier to scale a system vertically because it doesn’t require significant changes to the application’s code.
Immediate performance boost – Adding more resources can provide a direct and immediate improvement to the application's performance.
Cons
Physical limits – There's a ceiling to how much you can upgrade a single server, determined by the hardware's maximum capacity.
Downtime – Upgrading hardware might require downtime, which can be a drawback for systems requiring high availability.
Cost – Beyond certain limits, it becomes very expensive to increase server specifications.
Horizontal Scaling (Scaling Out/In)
Horizontal scaling means adding more servers to your pool of resources to distribute the load more evenly across them. Instead of having one super-powerful server, you have multiple servers sharing the workload.
Pros
Flexibility – You can add or remove servers based on demand, making it ideal for handling variable workloads.
No physical limit – Since you’re adding more machines, you’re not limited by the capacity of a single server.
High availability – If one server fails, the system can reroute the load to other servers, ensuring that the application remains available.
Cons
Complexity – It requires more sophisticated management, load balancing, and possibly changes to how the application handles state, sessions, or databases.
Networking overhead – More servers mean more network traffic, which can introduce latency and complexity in communication.
Choosing Between The Two
A senior engineer thinks about scalability from the outset of their projects, considering both short-term and long-term needs.
Those needs include both the technical and business requirements, such as:
Expected growth – How is your application expected to grow in scale?
Architectural decisions – What is more important: availability or performance? Simplicity or flexibility?
Maintenance and team capabilities – Who will maintain the scaled infrastructure, and what are their talents and capabilities? How will maintenance impact engineering capacity?
Cost – What budget is available to the team and the organization?
For applications expected to grow significantly and unpredictably, horizontal scaling offers more flexibility and scalability. On the other hand, for applications with predictable growth, vertical scaling might be a simpler and cost-effective choice initially.
Imagine you’re running a social media application. In its infancy, vertical scaling might suffice to meet your needs. However, as your user base grows and traffic spikes occur unpredictably, horizontal scaling becomes essential. You'll need to design your application to efficiently distribute requests across servers, handle sessions consistently, and synchronize data across multiple nodes.
Until next time, ciao!
Aken 💙