The question “what NOT to do to grow” is sometimes more important than the question “how to grow.” Most of these things will seem familiar and simple. But it is precisely these problems that greatly complicate the scaling of projects.

Golden hammer

The concept of this comes from an American saying:

If all you have is a hammer, then everything else looks like nails to you

Many developers are victims of this idea, using the same technology for any solution. Using technology to solve problems for which it is not intended is one of the worst mistakes in development.

A good example is using Redis probabilistic storage instead of MySQL to count the number of unique occurrences. This is an example where resources in two cases will differ thousands or even millions of times.

It is important not to confuse use with the game. At the first slow request, you don’t need to change the database, it needs to be optimized. The main thing is not to forget that the intersection of tasks solved by various technologies can be very large.

Lump of dirt

It’s not so scary to have some bad decisions inside the application, like try to make the whole application perfect. The result of quite frequent attempts by brave programmers to do this usually leads to a solution that is even worse than it was at the start in terms of ease of support and development.

Why is this happening? Any application, especially a growing one, is an evolving organism. Any problems are temporary, some cease to be relevant in a day, some in a few years. The attempt to “rewrite in the normal way” almost always leads to failure, because at the time of design, no one can predict the future.

As a result, from one lump of dirt turns another.

A lump cannot be avoided. But you can learn how to effectively manage it and reduce its impact on the system. Microservices are a good approach.

Hero

Many are familiar with the presence of a “hero” in the team, who has the solution of all problems. It is clear that this approach does not scale and is very risky.

A good solution to this problem is automation.

If your hero is a robot, it’s not so scary.

And in the process of growth, always try to use at least two developers, it is both reliable and convenient.

Not automation

The truth of the development is that there are always 10 times more tasks than resources. Intuitively, we try to solve as many problems as possible. But in the end, we fall into the trap of simple urgent tasks. They can be solved faster and more, creating the feeling that a lot of work is being done.

10 simple tasks will give the impression of more work than one large and complex.

Automation can bring significant results, increasing team productivity tens of times. Developers are good not only because they can develop a program for customers. They are also good because they can automate their own work.

To move along the growth line, relying on automation, it is necessary to provide a process of retrospective and planning. A retrospective will help to understand which manual work can be automated. And planning is to include the necessary improvements.

It is important not to fall into the trap of re-automation. If some action needs to be performed once … twice – this is usually a bad candidate for automation.

Not measuring metrics

Monitoring (in the broad sense of the word), like testing, is often one of the first to be sacrificed. Well, that’s understandable, it’s better to fix a known problem than to measure something.

To fix a mistake is an instant result, to learn how to measure work is a long-term result.

It is not so important which monitoring to use. This may be tracking the load on the processor and the number of requests in the DBMS. Or maybe the number of products views and additions to cart. The main thing is to measure and observe all business-critical events. Only then can you answer two questions at any given time.

Is everything alright?

If not, what exactly is bad?

TL; DR

Building growing systems is not such a complicated process if you follow a series of simple rules.

• Use technology at the needed place.
• Do not try to build the perfect system; focus on change and simplification. Think about using microservices at some point.
• Avoid team heroism.
• Automate, so you don’t waste time doing stupid work.
• Measure important indicators to keep up with issues.