To drive development faster, you need to slow down.

From the translator:
The beginning of the year is a great time to evaluate the past year thoughtfully. Take a wide look at what is happening and understand how to make the year 2019 better, calmer and more productive. In this case, we found the article How to Slow Down to Go Faster Than Ever in Software Development , written by Lemi Orhan Ergin, useful . And we publish its translation below.

Key points:

• Haste does not make us faster or more efficiently; it increases stress and makes it impossible to focus. Instead of haste, creativity, efficiency and focus are needed.
• Hire the most talented professionals, work together, practice and learn together. So you will increase professionalism and create a culture of excellence in the company.
• Increase team flexibility and process efficiency by making plans and regularly checking with them. Find, analyze and eliminate any sources of waste of time.
• You cannot be flexible without a quality code base. Eliminate defects, release versions more often, write tests before writing the main code, refactor, focus on simple design.
• Working software does not mean well developed. Only true professionals can build good-quality software that allows you to grow as fast as possible.

The fastest possible accomplishment of tasks can become your enemy if you are engaged in development uncontrollably. There are three important areas where it is worth slowing down: people, process and product. Before we dive into the details, let me tell you a story.

As I recall, it was 2011. I joined the team that created the online marketing platform. My main task was to add new features as quickly as I can. I was a senior developer. We call developers "senior" when they develop faster than others, right? However, when I started work, we noticed that it was almost impossible to work quickly because of technical debt and shortcomings in the design of the system. We also noticed that with each attempt to accelerate, we increase complexity and destroy quality. I came to the conclusion that the only way to accelerate is to rewrite the system from scratch.

I remember how during a telephone conversation with the product manager I said that we need to rewrite the entire system. After 30 seconds of silence, the manager asked: “You say that your team has developed a product of such poor quality that now the same team must rewrite the same product again, but this time do better. Right? Sorry, but this is unacceptable. You should have written it better right away. ”

Zombie software needs to be rewritten, again and again

According to the Standish Group's Chaos Report , 94% of projects were reworked from scratch more than once. This is a huge number. Recalling the projects I worked on, I understand that almost all of them were rewritten from scratch on new technologies, with new architecture and design. Rewriting from scratch is such a typical phenomenon for our industry that companies often view it as the only way to develop and manage a project. First we write, and then we rewrite and rewrite, again and again.

We need to know our main enemies. Speed ​​is a vital quality when developing software. It is important not only to enter the market first, but also to quickly respond to customer feedback, add features and fix bugs, so that users are happy with the product.

But we all have problems with the concept of "speed." We believe that fast-forwarding and reasonable and effective actions are somehow related to setting deadlines. We think that the result will be achieved faster if you work more or attract more people. As a result, we either add new people to the project, or work overtime to speed up work. Haste does not make us either faster or more productive. Haste creates a stressful environment, deprives us of the opportunity to focus on work and destroys productivity. We need the same creative approach, efficiency and concentration.

Software development is damn complicated. We cannot get rid of this complexity. Therefore, we need to live with her. The requirement to work quickly creates an unstable, restless atmosphere, immerses us in stress, makes it impossible to work productively and with concentration. This approach simply does not work.

Team performance (capacity), master plan, labor cost estimates, fixed working hours, deadlines and team velocity are all illusory. Incompetence is real. The speed of delivery directly depends on the professionalism of the people, the efficiency of the processes and the quality of the work performed. More often than not, the developers themselves set their own internal deadlines, even if there is no need for this.

As a result, we get a legacy system. The pressure of deadlines combined with incompetence lead to the legacy code - a dead end for the further development of the system. I used to use a different name for legacy systems - zombie software. This definition fits better, because legacy is literally dead software, but which looks like it is running on production. It works and even makes money, but it requires the blood, lives and energy of the developers in order to work somehow further. Developers are afraid to touch the code that works, no one wants to develop it.

Robert C. Martin spoke very well about legacy systems on his twitter : “If your software gets harder and harder to develop, you are doing something wrong.” Working in a hurry, we reduce quality so much that with each step the work slows down more and more. I’m sure: the only way to develop faster is to slow down the process until we reach stability.

Haste in software development is evil

In one of the CleanCoders series, Robert C. Martin said : “The main value of software is the ability of the system to adapt to future changes and simplify their implementation.” Hurry is evil when developing software. Any attempt to hurry will lead to a serious decline in productivity, focus, efficiency of people, adaptability to changes and flexibility of software.

For example, we always have time to correct bugs, but there is no time to write tests. We do not refactor and do not write tests, because we have little time. But then we always have time to debug, drive in crutches and fix bugs.

We are so focused on the process that we often forget about the most valuable for software development - people. Processes help people make a higher quality product, raise motivation and cultivate a healthy work environment. Ultimately, process effectiveness is important, but there is nothing more valuable than people.

It is necessary to understand that nobody and nothing is perfect. Customers, managers, managers, team members, business representatives, even you are not perfect. Requirements, documentation, tools, code, system being developed and its design will also never be perfect. So, we must stop rushing and mindlessly speed up development. The only way to move faster at a steady pace is to slow down in three important directions:

• People - increase professionalism and skill,
• The process - improving flexibility and efficiency,
• Product - quality improvement and automation.

Where to slow down when it comes to people

Processes and tools do not create a product. This is done by people. It is necessary to recognize that “hiring talents” is the most important task of the company, which has a direct impact on the future of the company as a whole and of the product being created in particular.

Hire the most talented in your organization. Speaking of "the most", I do not mean the smartest and most experienced. I am looking for at least enthusiastic, disciplined and motivated. If a person has these three qualities, he will easily develop his talents.

Hiring should be beneficial to both parties. So slow down the hiring process and take the time to improve it. People join the companies they believe in. Model what people you expect to see in your team. And make talented people believe in you, looking at your culture, your vision of the future and your employees.

Ego is a poison that slowly kills your organization. Never allow it to enter your organization. Starting from pleasant to talk fools and ending with brilliant assholes - do not let the extremes become part of your team. Do not hire people with bloated ego. With them you will never create a corporate culture that will delight others.

Stop working alone, work together. Do not allow fragmentation in the team. Singles and hero-developers are a sign of organization dysfunctionality. Sit close, close. Set standards with the whole team. Work in pairs or groups; do a review together. Allow all participants in the process to be responsible for the outcome.

Practicing together is the most effective way to pump your skills. By interacting, we not only inspire other people, but also learn from each other. Regularly organize the whole team code retreat , coding dojo and randori . Spend 30 minutes every day just by practicing.

Let knowledge spread among people. Learn together. I conducted Brown Bag / Lunch & Learn sessions with all the teams I have been working with since 2010. Twice I heard from my colleagues: "Participation in sessions on Wednesdays allows me to pump, and this motivates me very much." This clearly reflects the benefits of holding regular internal meetings.

Collect feedback and give it to others. Arrange a Big Retrospective to collect collective feedback. I have been doing this for years. By the way, this is a great way to dive into problem solving with a group of 20 or more people.

Teaching others and sharing knowledge is the best way to achieve mastery. Speak publicly and contribute to the community.

It is considered that developers hate to write documentation. But the reality suggests otherwise. Any result that other people read is documentation. Starting from the system code and ending with the test code, from messages to commits to the graph of commits in the repository, from messages in logs to error messages - the developers create a lot of documentation without realizing it. And whatever you document, if people read it - document it as best you can.

You are not children. Organization is not your parents. Everyone must manage their own careers and invest in themselves. If your contribution implies a waste of time or money, do it for yourself.

How to slow down and improve the process

Every day we face new challenges. This is not only the needs of the market and new product requirements. Technical challenges also affect our progress.

Plans are nothing, but planning is everything. Make a plan and constantly review it. Especially in the early stages of the project, when you need maximum flexibility. Daily reconciliation with a plan, such as daily scrum or daily standup, is not enough. It is necessary to interact more closely within the team, work in pairs and check the plan even more often. Keep the minimum length of iterations up to one week. Organize multiple feedback channels by conducting regular reviews and demo sessions.

Identify short-term and long-term goals. Short-term goals set the focus for the team, long-term hinder its loss.

If you want to understand why something is going wrong, visualize the work flow, both from a technical and organizational point of view. Visualize mistakes and failures to maximize learning by doing.

Never make decisions based on feelings. Always collect data, analyze and make decisions based on them. It is also important to provide each developer with access to product and technical metrics. This increases the involvement and understanding of the product being developed.

Waste is all that you spend time on but has no business value. Find and eliminate waste in the office, in code and in business processes.

Boy scouts leave the parking lot cleaner than when they arrived. The same philosophy applies to software development. Follow the scout rule and leave the code cleaner after each change. If you are going to add a new functionality and you see in the file shortcomings that can be fixed - do it without asking permission. Do not forget to write tests first. This will give you confidence when making changes.

You can detect waste at any point in the system development cycle. Follow the well-defined criteria of readiness (definition of done) and eliminate tasks in the spirit of "90% completed, there is still 90%."

Do not allow the emergence of long-lived branches - they are considered evil. Do not check your code manually. With manual testing, you are more likely to test a successful execution script. All other scenarios can only be verified using code. So take this matter seriously.

How slowing can improve product quality

One thing is for sure - without a high-quality code base, you cannot be flexible, excuse me. The first thing to do is to eliminate technical debt and correct mistakes. If necessary, stop the development of new functionality and focus on correcting errors.

The approach “I will quickly fix it, then we will understand it” does not work in the current realities, because it is too risky. When eliminating errors, a more disciplined approach is needed. First of all, write a test that reproduces the problem. After that, fix the bug and make sure that the test now passes. Now you can safely send the patch to production.

I worked in teams that spent almost all their time correcting errors and supporting the project. The reason for their suffering is unstable work at production. To continue to develop new features, while correcting errors, you will have to divide the team into virtual teams. For example, at each iteration we select two guys who are engaged in support and error correction. We call them Batman and Robin. Regardless of what functionality you are in a hurry to finish, bugs are fixed without interrupting the main development.

Often, developers and so use one of the practice of slowing down to further speed up - pull requests. They stop the current development, perform checks and conduct code review to improve the quality of the code. Unverified code never gets to production.

Our ultimate goal should be the transition to Continuous Delivery and frequent releases. Beginning with the use of git branches and ending with deployment strategies, from ways of providing feedback to automated testing practices, a special approach is needed for all of this.

The practices you use at different stages of the software development cycle clearly show how fast you are developing. When working with branches, use the “commit early, commit often, perfect later, publish once” approach. If working without branches, use Feature Toggles. This will eliminate waste of time.

I have been using TDD for several years now. Often people complain to me that TDD has a negative effect on the speed of development. Joe Rainsberger shared his thoughts on TDD on twitter : “ Are you worried that TDD will slow down your programmers? Do not. They probably need to slow down. ”

TDD is more refactoring than testing; thinking more than coding; more simplicity than elegance. This is why TDD leads to higher quality. When using TDD, you will only have a minimal amount of tests and a simple design.

Have you ever achieved 100% code coverage with tests? I reached it in a three-month project, covered every line of production-code with tests. At that moment I felt like a hero with supernormal abilities. But when we deployed the system for preproduction for acceptance testing, we noticed that four functions do not work. I wrote integration and functional tests to find and fix bugs. At that moment I realized that unit tests do not guarantee good design and working functionality. Stop counting the percentage of code coverage as tests. This metric does not show anything.

Correct errors immediately if it takes 30 minutes or less. Additionally, use 20% of the time to eliminate technical debt.

As a rule, we write code without intending to change it further. When designing a system, we likewise select technologies and tools, planning not to change them in the future. But we are wrong. Refactoring should be possible at any stage of the project. As Kent Beck says, we need to make light changes so that further changes are easy. To make this possible, we store the code of all our microservices in the mono-repository. This makes refactoring easy and really necessary.

Any decision in the design of a mistake, if it is made earlier than it became necessary. You should wait for the last acceptable time for a decision. We use the Ports and Adapters architecture to achieve low coupling and high coupling at the design level of the entire system. Because of this, we get well-designed monoliths.

Monolith is not evil, evil is bad design. We always start with the development of the monolith, and thanks to the “ports and adapters” architecture, we extract parts of the functionality into microservices. As Martin Fowler said in his Monolith First article : “It’s risky to start right away with microservice architecture, better start with a monolith. Separate into microservices only when and if necessary. ”

Slowdown to accelerate as an approach to life

Andreas Möller shared his feelings about software development in a tweet : “I don’t want to write code that just works. I want to write code that is clean, maintainable, easy to understand and well tested. ”

To achieve this, we need to focus on three areas: people, process and product. Slowing down the work of people, we strive to improve professionalism and skill. By slowing down the process, we strive to increase flexibility and efficiency. And by slowing down the work on the product, we strive to improve the level of automation and the level of quality. When we focus on these three areas, we begin to cultivate a culture that makes rapid development possible.

We must remember the following:

• A working system is not necessarily well written.
• Only true professionals can create a well-developed system.
• Only a well-designed system will allow you to release new features as quickly as possible.

about the author

Lemi Orhan Ergin is a software development master who seeks to raise the level of excellence in his industry and share his experience with the community. Co-founder of Craftbase and founder of the Turkish Software Craftsmanship Community . Engaged in software development since 2001. He actively practices and practices mentoring in such areas as Scrum, extreme programming, development methodologies and web technologies.