Increment development

Requirements development

Some young, enthusiastic, motivated programmers like to start programming when they just hear the client's request. From the "Technical Planning" section, you can predict that this is not about us, and you would be right. We believe that typing code is often the simplest task in product development. So we do not rush to write code until we are sure it is time.

First, we create a technical design of the solution and eliminate all technical risks. Every increment should fit into the product's constraints or reasonably change them, so we would not get problems in another part of the product. If you underestimate the technical threats and it turns out that it's impossible to implement some part of the task, you will have to throw away all the written code. We saved our customers a lot of money by testing the APIs of 3rd-party products before integrating with them. A few test requests could show that our assumptions are wrong, the requirements need to be redesigned.

Then we estimate the deadline and the cost of the solution. We make sure that the estimate is consistent compared to previous similar functionality and that it is reasonable to develop this solution now. Our solutions depend only on the product's needs and the client's operational plans.

We pay close attention to the technical design in the task definition. At this stage, we need to provide the full technical context so a programmer can consider all the factors and safely make the increment into the product. Precisely formulated requirements minimize threats and reduce development time. We often suppose changes to the data schema, ideas about optimal abstractions, and any thoughts around development process optimization. The programmer needs freedom in decision-making and clear acceptance criteria to provide high-quality code. So, we mainly advise the developer the way to build right solution rather than strictly dictate it.

We use a similar approach for bug fixes. Here we are in a specific context because the problem is apparent. We need to find out how to fix it without damaging the rest of the product. As a rule, such requirements are more pedantic. We need to show the developer how to reproduce the problem and guide him to potential parts of the product that could also be affected by the fix.

In the end, we only need to make sure that we formulate the problem correctly and consistently. Without a deep analysis of the problem, the programmer will return the task explaining why it is not reasonable to perform it as formulated. If something does not add up significantly, we will at least ponder on the correctness of the task definition or even return to the previous step. It is better to reconsider the work at the requirements stage rather than the quality assurance stage. In most cases, all these rearrangements do not require our customers' time.

We are critical about our work during the requirements phase. This approach saves our clients' budgets and helps us spend developer's energy only on worthwhile tasks.

Programming

No matter how well all the other processes work, the developer has the last word, and it depends on him whether the product will be successful or not. If programmers don't manage to develop the increments to the product in a timely, high-quality, and forward-looking way, then everything else will go down the drain. That is why we built all the work processes to create an optimal working environment for developers.

In the early stages of the product you must rely on programmers. Their speed determines the time needed to test hypotheses, and their work quality determines the accuracy of the results of experiments. Programmers' systematic work makes the product stable, which determines the success of the technology company. Therefore we strive to organize the best conditions for our programmers. High-quality solution of engineering tasks requires a wide outlook, deep technical expertise and sincere love for their work. We solve most of the significant problems at the design stage. Nevertheless, the programmer writes code and is responsible for the accuracy and quality of the problem's solution.

Nowadays, a developer must make his increment handy and readable for the other developers. As Robert C. Martin says in "Clean Code": "Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write." So, when the business requires clarifying, improving, and extending the solution, this effort pays off. Also, a programmer will spend the effort to make the solution more productive without sacrificing its clarity when such an opportunity exists, extending the product's ability to grow.

Every development solution must be overall in its field. In most cases, the product architecture dictates the proper solution. And the developer just needs to implement this decision. But when new requirements do not match it, the developer must adapt the system. In this case, the programmer needs to redesign the entities to fit the new system objectives. After a good entity redesign, the product will have new functionality without breaking the old constraints.

Finally, when the solution poses a risk to the product, or the problem is unsolvable under current requirements, a programmer needs to find a way out of the situation. Often they can refine the problem, making it solvable, or reduce the risk to the product. In complex cases, it is necessary to replace the task with an alternative or redesign the entire work block. This may require a lot of effort to find a solution to coordinate it with colleagues and the client.

The programmer is the first person responsible for the quality control process. Sometimes it is not clear whether you should handle some extreme cases and hypothetical scenarios. In such cases, the programmer can ask a colleague to analyze the decision together. Since our developers have a good understanding of the product's objectives, they can assess the risks properly.

The success of our products relies on the craftsmanship of our programmers.

User Interface Development

We develop products that are pleasant to use. We want our users to have only a good experience with them. No matter how great the code is, your product should be comfortable to use to succeed in the market.

We often engage other specialists to solve design problems when we need high-level expertise. In any case, the responsibility for the final result lies entirely with us. We focus on figuring out essential aspects of the user experience to deliver high-quality solutions to the end-user. When it comes to B2C products, the main focus is user comfort and convenience. For B2B products, the most important thing is to make interfaces effective tools to cover all business needs.

Most user experience tasks are about telling the user how to interact with the interface and handle a problem situation. Therefore these tasks can be effectively solved by our specialists. We create conditions for building UI design as well as for writing code. The same applies to the level of freedom in making decisions. We strive to give optimal space for creativity in the interests of the product.

We iteratively and quickly test our user experience hypotheses. In the early stages of product development, we thoroughly test internal and external audiences with user interviews or screencasts of user interactions. We study user interaction scenarios with the interface and make improvements as necessary. This approach allows us to develop user-friendly interfaces and interfaces that become tools for solving business tasks.