Or do it right

If you choose one idea that kills the most products, then this is future proofing.

Usually the idea manifests itself in a pattern.

We need {X} , and although it is much easier to make {Y} , but if {Z} occurs, the first option will simplify our lives.

Where {Z} - an event that may occur in the distant future.

Here are some examples:

• For infrastructure, Kubernetes and Docker are needed , although one large server is much simpler, but when we have to scale up to 11 servers , it will simplify our lives.
• To process the data, a distributed design is needed , although a centralized solution is much simpler, but when a customer requires 99.999% uptime in an SLA , it will make our lives easier.
• We need to recruit a team of developers and create our own software , although Wordpress and Shopify are much easier, but when the client base grows 100 times , it will make our lives easier.
• It is necessary to use a design based on type inheritance , although the composition is much simpler , but after 5 years of increasing the code base, this will simplify our lives.
• You need to write code in C ++ with caching of views, although a Python script with direct requests to Postgres is much simpler, but with a large increase in the amount of data, this will simplify our lives.

I recently wrote an article about imaginary problems that people invent themselves from boredom, not for good. Stock creation for the future usually falls into this category. I would even say that this is the most popular mistake in most small companies.

But it is worth further discussion, because creating a reserve for the future can really help the product, have it all done right. However, most people make mistakes and harm work.

Success is harder than living with him

Strange as it may sound, I think that one of the main reasons for this is the cult of celebrities.

People have a strange obsession - to put themselves in the place of someone more successful. Then they make plans from this position, but they do not think in their own way.

Everyone fantasizes what to do with the amazing power that he does not have. As if he is the president of a country, a billionaire, a celebrity, a virtuoso performer or a superman with superhuman abilities.

The problem of developers is that they indulge in these fantasies too much. Software can write to everyone. Not only Facebook is able to create a media platform that supports billions of users, but you waste your time. The magic of Facebook was to attract these billions of users, and scaling the system was the easy part.

Here are two aspects:

• a) Growth is much more difficult than technically ensuring it.
• b) The most outstanding and well-known engineers are working on products that need a scale.

The first point is obvious, if you think about it. How many software companies failed when they reached billions in revenue or millions of users? Maybe 80% ... if you define "failure" is very strict.

However, of all software companies ever created, perhaps only 0.05% ever reached such a scale.

The problem with stock creation is that it is usually created for scenarios that never come to life. Whether up to 1,000 employees, 10,000,000 users, or 10 large customers with draconian requirements.

And it is difficult to abandon such plans, because it interferes with the thoughts of success. It prevents people from fantasizing how they beat Amazon, and instead returns to reality. But in reality you have 50 clients, half of which are relatives and friends.

The second paragraph only worsens the situation. It is quite natural that the best programmers get the best places in leading companies. They either helped to create them, or millions pay for support there.

The Pareto principle works against us, since the best programmers write most of the books and give most of the lectures. We constantly hear about distributed services on thousands of machines that process petabytes of data and compete for every percentage of performance. But most of us don’t have to think about the scale or reliability of a system like Facebook or Google.

So if fantasies about the future do not help, then you don’t need to plan?

Of course not. Thinking about the future is important. It should be laid on him, but do it right.

Design for the sake of flexibility creates imperfection

When it comes to thinking about the future, less is more.

Very rare products correspond exactly to the needs of users, the rest are adjusted on the go.

It is hardly a coincidence that you provide service A and 90% of users need just that. Typically, you provide the service A , and 90% of service users need the Z . However, A  is the closest alternative to Z and no one provides Z ... therefore some customers decide to accept it.

It's good. When customers decide to come to terms with your product, you can change it according to their exact needs. In essence, users help identify a niche in the market. As soon as you can better fill this niche, then begin to grow.

This is a productive paradigm of thinking, because it encourages a “better less, yes better” approach to future development. Reserve for the future does not imply an increase in complexity, but rather the opposite - maximum simplification. To be able to adapt.

The simpler your code base is, the easier it is to configure it to perform another task.

"I hate the code and want it to be as small as possible in our product." - Jack Diderich

Perfect design requires sacrifice. Usually they are related to flexibility.

Often, it is the imperfect software that solves world problems, since the imperfect is more flexible. Imperfection by definition leaves room for improvement.

Design optimistically, the future may surprise you

It is also important to remember that the world around is not static.

Future problems need to be addressed by future technologies.

Many people not only do not think about future tools, but generally use the tools from a decade ago. They impose restrictions on themselves that have long been lifted.

I will explain on a specific problem: the design of distributed software. One of the most common reasons for developing such software is because a single server cannot scale to the required specifications. Although this is true in some situations, it is difficult to believe in the prospects of most projects, especially startups, which have almost no clients.

I think part of the reason is that most developers in 2018 are still thinking about the 2005 servers. But computers are improving every year, and many providers sell cheap dedicated servers.

For example, here is a cheap big server:

• Two Xeon E5-2680v4 (28 cores, 56 threads, clock frequency from 2.4 GHz to 3.3 GHz)
• 512 gigabytes DDR4-2400 RAM
• 2 NVMe SSDs at 1.2 TB (each ~ 3 GB / s read, ~ 1.5 GB / s write)

I can bet that most distributed software requires a workload of less than half the power of this amateur server.

Such a server costs from ~ 800 to $ 1,300 per month depending on location. You can take a dozen for the salary of an experienced DevOps engineer in London.

More pleasantly, the server will be twice cheaper in two or three years.

Computers continue to improve, and they will do it linearly until the end of the 2020s. Who knows what inventions will appear. By that time, we can even see the open-iron revolution .

Nevertheless, people continue to develop software for hardware specifications and prices of the early 2000s, although in 2018 it is necessary to develop software for 2019 machines.

This applies not only to servers. If you want to think about the future, think about all future peripherals. I am sure that the guys who provided the voice interface for their device in 2016 are quite happy in 2018.

What periphery to prepare for in 2018? God knows. But I know that it has not yet become popular. When it becomes popular, it will help you to take a monopoly position in the market, because you have already adapted your software for it.

And it's not just about hardware, the progress in software is absolutely amazing. With the advent of WASM, browsers are becoming universal virtual machines. After two years, you can build a high-performance application by compiling it for a single platform: WebAssembly.

Despite this, people still create software for 2012 home computers. They use Babel, although 99% + users have browsers with ES6 support.

New languages ​​are constantly appearing, and some of them are very good. Only in the last 8 years, Go, Rust, Scala and D have appeared, which have completely changed the paradigm of system programming. In the next two years, it seems to me that Julia will make the same revolution in scientific calculations ... and these are only areas that I personally deal with, and the total number of future amazing things is just incredible.

But I digress ...

Easy to enjoy the future. But no one really knows what will happen in a year or two to five years. There are some predictions, but they are naturally not perfect.

However, if you really want to create a stock for the future, then first understand what the present offers. Everything else, so you make a more accurate conservative forecast based on real data.

Software with a reserve for the year 2020, made in the spirit of the early 2000s, will not help you with anything.

So don't stop thinking about the future.

Just start planning correctly.

Design, taking into account not only your product, but the entire surrounding ecosystem.

Design for flexibility, not perfection. Flexibility ultimately helps to adapt software for the future. It helps to take on new challenges, rather than protecting them from imaginary ones.