Do you ever feel like the work you are involved in is too chaotic or that products take too long to deliver? We have an answer. Today we will share Rule 3 of the Scalability Rules on how to simplify scope, design, and implementation and deliver your product faster.
Often, we work with clients who are stuck in a slow development cycle where it takes too long to get things done. They watch the market come and pass them by. They have good ideas, but they can't seem to get them out.
We've seen the same thing with startups. Lots of passion and excitement to start off with, long days, and hard work. But the product doesn't really take shape. People aren't buying as hoped, and eventually the team drifts apart.
Let’s talk about how to not let that happen. Let’s live our dream, see it come to reality, and bring joy to the people who would use it.
Simplify the Scope
When simplifying the scope, we are trying to cut down the problem. Make it smaller, make it simpler, and focus on what matters.
In the book "Rework," authors Jason Fried and David Hanson write:
"A lot of things get better as they get shorter. Directors cut good scenes to make a great movie. Musicians drop good tracks to make a great album. Writers eliminate good pages to make a great book. We cut this book in half between the next-to-last and final drafts. From 57,000 words to 27,000 words. Trust us, it’s better for it."
So, how do we find the important part, the part to keep, the signal in the noise of our own product?
The Pareto Principle
To start with, remember the Pareto Principle. It states that for many events, roughly 80% of the effects come from 20% of the causes. For a product, what 20% of the features create 80% of the value?
You can always do less.
At Signal v. Noise, David Hansson wrote a blog titled "You can always do less." In the post he suggests:
"For every 1 day estimates of a task, there is a simpler version that you can do in 3 hours, and a simpler one you can do in 30 minutes."
An example of a mistake I made on this was for a project that needed to automatically submit pdfs for printing. Each day we wanted someone to decide if the submission should take place. If so, they marked it and it would print that night.
Thinking myself clever, I also added the ability to set the date for the next submission. It took half a day to test and get right, but that feature wasn't really necessary. At best it was a mistake with an opportunity to learn a lesson. I should have used that time to get the core feature complete. Sigh... live and learn.
So, what is the simpler version of what you are doing?
The other side of complexity
Simplicity, for the sake of simplicity, is insufficient by itself. We are looking for simplicity on the other side of complexity. Or as Oliver Wendell Holmes Sr. put it:
"I wouldn't give a fig for the simplicity on this side of complexity; I would give my right arm for the simplicity on the far side of complexity"
Our first step is to deeply understand the problem (complexity). Once we do, we then look for how to simplify the solution. How to communicate about it. How to prove that we understand it. How to share it.
As an example, putting things in space was a hard problem. Solutions were costly, complex, and rocket launches were not common. On average, NASA would spend $152 million per launch.
Enter SpaceX. They've reduced the cost to $62 million for a similar launch. In 2021, they have the goal of over 60 launches, averaging more than one a week. As a company, they understand the complexity of rocketry, and now they are simplifying it. Perhaps in our day travel to the moon and Mars will be a simple experience, like catching a flight on an airplane.
Find your simplicity on the other side of complexity.
Great. So, how do you find it?
Get the right things very very right
Paul Buccheit, one of the creators of Gmail, wrote a blog post titled: "If your product is great it doesn't need to be good." In this post, he talks about focusing on the most important features. In his words:
"What's the right approach to new products? Pick three key attributes or features, get those things very, very right, and then forget about everything else. Those three attributes define the fundamental essence and value of the product -- the rest is noise." ... Put another way, if your product is great, it doesn't need to be good."
Do you remember when Gmail came out? Before it was available, there were dozens of email programs; Hotmail, Aol, and Yahoo to name a few.
They were all bothersome.
As a user, I wanted to read email and find conversations easily. With all the ads and lack of organization of the other providers, it made it quite difficult to do the job.
Then Gmail came out. Enter hallelujah chorus!
- No ad clutter in the free space around the email content.
- Email threads are grouped by subject and have a natural flow to the discussion.
- Learning algorithms are used to catch SPAM before I even see it.
- Not to mention the cool marketing plan. They only gave out a few accounts to begin with; the exchange rate for these was like gold!
Joy and happiness! They delivered a nearly perfect tool for communication. Even now, 16 years later, I am very satisfied with Google's product. In contrast, have you seen the clutter in other email clients? Did they not learn anything from Gmail?
If you are building a product or service, get the core features right, very very right. Then, if you are great at that, you don't have to worry so much about the other features for the time being.
Simplify the Design
With a simplified scope, let’s talk about simplifying the design. The design will be the plan for how we are going to build our product. This step asks how to get the job done in a way that is easy-to-understand, cost-effective, and scalable.
Easy to Understand
The moniker "Keep It Simple Stupid" is important at a high level and has a cool acronym (KISS). But simplicity isn't easy. It takes deep understanding and effort to boil out the essence of a problem. It has been said that "Simplicity is the ultimate sophistication." Once achieved, a similar skill and effort is required to communicate the design for implementation.
Two things that will help, are to plan the architecture and diagram the process.
The architecture describes how parts of the system interact. It includes an understanding of where bottlenecks might appear so they can be mitigated.
To communicate the architecture, we want a flow chart or diagram. This diagram illustrates how data flows through parts of the system. Each module in the system should have clear inputs and outputs. With a picture of the system and clear inputs and outputs, it is easier to understand how to build each part.
Cost Effective
For a cost-effective design, think about the path data takes through the system. Is there static content that is retrievable once that could be saved in a cache? Could a content delivery network (CDN) simplify the distance the data travels?
Is data retrieved, a calculation performed, and the results used? How often does the underlying data change? Could the computed results be saved so future requests don't repeat the work?
What is the fewest number of steps that data must take to get from the user to the database and back? Would small monolith services be better than microservices?
These questions get to the root of a cost-effective system.
Scalable
Use the AKF Scale Cube to think about how to build the project for scale. The scale cube provides a standard way of thinking about scale.
With a simplified scope and design in place, we next look at how to simplify the implementation.
Simplify the implementation
In this step, we are actually building or coding the solution. When it comes to building, there are lots of questions to answer:
- Should we use recursion or iteration?
- What language or framework should we use?
- How are we dealing with memory and storage?
- Do we make a solution, use open source, or buy it?
Finding the answers
The answer to all these questions has a consistent theme. "How can we leverage the experiences of others and existing solutions to simplify our implementation." Here are some steps to follow
- Is there a widely adopted open-source solution that meets our need?
- Is there a third-party solution we could buy?
- Is there a white paper or third-party solution we could legally copy or mimic?
Only in the absence of one of these three solutions should we embark on "rolling our own." The reason for this is that the risk of building something new and untested will take time, be costly, and errors are bound to happen.
The simplest implementation is one that already works and is in use.
Building or Integration
Once we know what solution we are going to use, we either need to build it or integrate it. There are a few things to keep in mind that will further simplify the implementation.
When integrating an existing solution, take care to not change the solution. First, focus on connecting to it and make sure you understand how it works. Then, modify the solution as needed to fit your particular use case. By changing fewer variables at a time, you are able to focus your work with minimal distraction.
When writing code, there are plenty of principles to follow such as KISS, DRY, SOLID, SLA, and finally TOP. Once you have these down, there are plenty of design patterns you could learn and use as well.
Following the principles and patterns should lead to writing good, maintainable code. Here are a few things to keep in mind
Focus on readability - Code that is easy to read is more enjoyable to use. It also lets you focus on the problem you are trying to solve. It minimizes the time and effort to figure out what the previous developer was thinking.
Break it down so each part solves one problem - Keep it simple and have each part do one thing and do it correctly. Group similar parts of the project together into shareable libraries.
Do it right the first time - How many times have we heard, "Well I didn't have time to do it right?" .... Sure, but you had time to fix it? Try not to build any technical debt in the system; build it right the first time around and you will thank yourself later.
Unit Testing - Add basic unit testing to make sure each part does what you expect. This gives you a safety net when making changes. The safety net keeps your stress down and allows you to focus on what is important.
Automate as much as you can - Depending on where you are in your product development cycle this may be a little or a lot. At least start with automated unit tests on check-in. As your product progresses, move to a CI/CD deployment.
Conclusion
As we understand the complexity of a problem we are working on, we want to simplify the solution. This happens when we simplify the scope, simplify the design, and simplify the implementation.
By following this 3rd principle of reducing the equation from the book Scalability Rules, you'll quickly realize that you can do more valuable work in a day with less stress, less overall cost, more happiness, and greater personal peace.
You'll be amazed what you can do when you simplify.
So, simplify!
Can we help? Call us!