The same principles are relevant for a mature company that has managed to occupy its niche in the market. Especially if a company on the wave of success starts to scale uncontrollably, bloats its staff, and becomes sluggish. In the end, it may lose competition to younger players who are able to develop their product faster to meet market needs or make it cheaper through more efficient development.

The main misconception of developers

Everyone is interested in the efficiency of the development process, including engineers themselves. The easier and more painless the team manages to make changes in the product, the more comfortable the working day becomes and the higher the morale of all team members.

Unfortunately, very often I see the same mistake made by people with a technical mindset, focusing too much on one aspect that seems crucial to them. In practice, it may have no effect other than psychological, leaving all of the above problems unresolved. Let's start with the most vivid example.

Selecting a technology stack

The most intuitive solution for an engineer is to find the best, new, modern/publicized tool and believe that it is impossible to write bad code on it. That you can realize the same task many times faster than before, that there will be fewer bugs, etc. I will only list what I have directly observed in my practice.

Ruby on Rails - a new generation MVC framework where everything is thought of for the developer. Functional Programming (Clojure as an example) - a separate world for a select few where you don't have to suffer. TDD - maximize code coverage with tests, and catch bugs earlier. Test First helps to design modules better. NoSQL - flexibility and scalability. GraphQL - no need to waste time on new API handles, the frontend will pick up everything it needs. Sound familiar? You could go on. React.js - the savior of the frontend, to which you need to urgently switch from any other framework and forget about problems on the client. Redux - now for sure on the frontend full happiness. It can't be any other way.

Is all this not true? Yes and no. Technologies can be great, but they don't solve the original problem of product development efficiency, because they are just tools. Imagine you are building a multi-story building in a harsh climate with challenging terrain and capricious soil. You have modern cranes, air blowers, lasers for setting levels and all the necessary tools in the hands of workers. Is it enough to build a sustainable building that will last for decades and not collapse under the influence of a fickle environment? Obviously, no. The key will be for architects and engineers to accurately calculate the load on the supports, examine the soil for suitability for high-rise buildings, and take into account the temperature differences between winter and summer.

In software product development, the situation is about the same. This brings us to the next efficiency factor.

Architecture

In short - with a mediocre architecture, using even the best tools, development will be effective for a very short time. Timelines will stop being predictable at some point, and additional iterations of bug fixes and stabilizing releases will start to appear. Technical debt will grow and take up more and more time. Conversely - even with a not-so-modern stack, investing in architecture can provide a stable delver for the business. Maybe not at the highest possible speeds, but more importantly, in a predictable timeframe.

A short example from the frontend world: the popular bundle React.js + Redux. At some point the hype reached such a level that all new projects used this stack, in full confidence of their success. The problem is that React is just a view library for rendering components, and Redux can do nothing but save state to one huge global stack. These two libraries, in theory, made it possible to write anything, but offered no ideas on how to organize the application structure, modularity, separation of logic into layers (view, business logic, application logic, API), allocation of domains and bounded contexts. As a result, every React project was a bicycle, randomly structured, with a huge accumulation of logic in the View layer or in the Redux store.

What conclusion can be drawn from this? First of all, you should make sure that a long-lived project has enough expertise at the start to create a reliable architecture, and only then choose tools. I emphasize that it is expertise. What position a person holds is not so important.

But is it enough to bring the development to its maximum speed, or is there something more important than architecture and tools? It seems that there is.

Management and Processes

This item is less relevant in micro-projects at the startup when the whole team fits into one open space or one daily sync in Zoom. But that doesn't mean it can be neglected. We have an architecture and a powerful stack that helps engineers close tasks quickly and with good quality. But how is the development process organized? Does the team do an evaluation before they start development? Is the development process parallelized or is everyone blocking everyone else? At what point are uncomfortable requirements questions asked: when development has already started or before giving an estimate? How are tasks distributed within the team? Is there no imbalance when one part of the team is overloaded and the other part is bored? Consider an example:

You need to add a new reviews or comments section to a product, such as a product. This feature includes a new design, a new API, and a new screen or widget on the front end.

Option #1 - take it and do it

1. We wait for the design (2 days)

2. Look at it - it seems to be fine. Start making API (4 days)

3. API is ready. We start making the frontend (another 4 days). At the end we ask ourselves "Should new reviews appear automatically after loading or only on the next visit to the page? It seems that we didn't provide for this in the API...". Spent another 1 day on discussions and an additional crutch in the form of periodic jerking of the handle from the front end. In parallel, we are already afraid that the API may become bad from such a volume of requests, but there is no time to redesign it.

4. we give it to testing, fix bugs (3 more days).

5. Everything is tested, we can move to the master. We create a huge Merge Request, code-review by the rest of the team starts. There are a lot of comments, it is long and scary to fix them because the feature has already been tested. Making serious changes will require re-testing. (+3 more days)

   Total - 17 days, we already have tech debt, and we are not on the proda yet.

Option #2 - evaluation, contracts, parallel development.

1. The design does not depend on the team's employment, so it is drawn in advance at the first request from the business "on the table". At the moment when the team is ready to take on a new feature, the design is ready.

2. We watch the design, ask questions (including about the automatic appearance of new reviews). Describe the contracts for the new API, discuss them with the frontend team. Spend an additional 1 day on this preparation.

3. Start backend/frontend development in parallel on the contracts, agreeing on which API handles to give out first for integration. As soon as the first working end-to-end scenarios appear, QA starts testing them and reporting bugs, which are closed in parallel with development. We decompose a feature into small tasks and submit them for code review atomically, as they are ready. Promptly review and correct comments in small portions (5 days for everything).

4. At this stage we have already finished development and fixed most of the bugs. We fix what's left. (Day 2)

5. All code has already been reviewed in the previous stages. We can merge it into the master.

   Total: 8 days, without tech debt, with preliminary estimation and understanding of when the feature will be ready for release on prod, with the accuracy of a couple of days.

Who is responsible for this? More often than not, the teamleader. Although, as in the previous point, the position is secondary.

It would seem that we can finish here, because now development is already moving like a locomotive, right? Almost right. We already have a clear plan, instructions, roles and tools, but the most important thing is missing.

Team and hiring

The ingredient I subjectively consider the most important of all. It can, in practice, both offset the absence of any of the above items, and prevent them from being capitalized on at the outset. What you need to start developing any serious product with. Hiring and building a professional team.

This topic is so vast that it deserves a separate article. For now, I will only formulate the main theses:

1. Professionalism and responsibility are the number one quality.

2. Proactivity. A person in any position in the team feels dissatisfaction if he sees some unresolved problem. He does not wait for tasks from above, but takes the initiative himself.

3. Soft-skills are as valuable as hard-skills, sometimes even more valuable.

4. Ability to work for a team. Quite difficult to check at the interview stage, but possible.

Why is it so important? It's not always obvious, but the most expensive part of development is not the process of writing code, testing or bug-fixing itself. The most expensive part is the unnecessary iterations at the intersection of different stages of development and different roles on the team. How many times will a backend engineer deliver a truly working API to the frontend team? How many times will a tester have to retest and return the same task for revision before it's suitable for production? Can we close all requirements issues in one meeting before development starts, or will we be constantly stalled in the sprint process and have to come up with corner cases on the fly?

Professionals with all of the above qualities will intuitively save you time at every stage, and you don't even have to ask them to do so. They care about the result. Such a team can effectively delver even with a non-ideal architecture, not the most powerful stack and even without calibrated processes. Therefore, I believe that human resources are the most important factor of effective development success, on which everything else is built.

Conclusion

My top in order of importance looks like this:

1. Team and hiring

2. Management and Processes

3. Architecture

4. Technology stack

There are exceptions to this hierarchy. Sometimes the choice of stack can have a significant impact on team structure and development processes. For example, a cross-platform framework for a mobile app, as an alternative to separate iOS + Android teams, can significantly reduce the time to market for a mobile product while reducing the cost of development and testing. There will probably be a separate post about this. Even so, prioritizing it in the order suggested would not be a mistake in my view.

Thank you all for reading to the end. I hope the material was of some use to you. This post is purely of an overview nature. In future articles, I'm going to disclose each point in more detail. Stay in touch.