Program less, think more ... incrementally
Unfortunately, examples of projects on which developers have spent a lot of time, say more than half a year, but never published, are not uncommon.
Fagner Brek believes that this happens because these projects did not implement the principles of continuous integration. In his note, the translation of which is in front of you, he writes that, in the case known to him, something needs to be done differently from the very beginning:
But how to do that? This is a fundamental question that everyone has to face in a software project: everything will change.
')
How can you continuously integrate a project every day if it takes months, not days, to complete it?
Instead of asking “how to build a big project?”, You should ask: “how to divide a big project so that I can build the smallest useful piece?”
The idea of ​​iterative development is to find different ways to solve the problem. It aims to realize a large project moving in small steps , rather than aiming directly at the ultimate goal.
The popular comic in the title picture illustrates this approach very well. In the upper example, which is entitled "How not to do," the user is not satisfied with all the steps except the last. In the bottom he is not satisfied with the first step, but starting from the second step, he likes it more and more. Moreover, the end result in the lower figure he likes much more than in the upper one.
But something in this comic is not entirely obvious.
In the first example, the result is a machine with a hard top. Because when a user ordered a car, he was married, and naturally, it would be desirable to have a closed car. However, somewhere in the middle of development, the user got divorced and changed his mind - he wanted a convertible.
The developers have already begun with the overall picture of the “ big project ”. The wheel was built specifically for this model, and there was no way to change anything in the middle of the process. The user received what he requested , although this is not what he wanted .
As a result, the user is just satisfied.
In the second example, the task was to make a tool to move quickly , and not just get a car, so it was possible to make changes to the plan throughout the process. The developers built a convertible in response to an unexpected end to the marriage. In the end, the user was able to change the wishes despite the fact that they differed from what he asked.
Now he is happier.
There is another non-obvious point.
In the first example, the construction of the car took 4 steps. However, in the lower example, it took 5 steps to come up with a convertible.
Actually, iterative development doesn't really make you “faster . ” If you define "speed" as the amount of code written in a certain time, iterative development may take even longer to complete the entire project.
However, if you consider “speed” as the sum of the value you received, then it is possible that you will need more time to do something, but less time to complete it. The trick is to build a minimal viable piece that can make the user happy, even if it is not the final big project.
What people want will change, and the initial request will become obsolete. Or, as I said before - everything will change.
The only thing that can be done is to accept this fact from the very beginning and plans accordingly.
Do not try to change the world, swim in the stream .
In the convertible example, developers didn't need to know what the user wants. They simply worked on the problem of fast moving, and always in the right direction.
Note: you can argue that comics are a bad example that does not correspond to reality ... and you are right. In the comments to the original article, the author responds to such a remark.
The principle of iterative development can be applied to almost any area, and not just to the one with which the user interacts.
Programming some small pieces all the time, you can discover new information that can change your vision of a “big task”. It is also a way to avoid problems, when much more is done than was necessary , and to take into account changes in your own understanding of the problem.
Suppose you decide to participate in the universal cryptocurrency madness and have begun to make some buying / selling operations on several exchanges. However, these exchanges do not allow you to clearly view the profit / loss from your current and future sales. You can create a website.
The site will connect via API to the right exchanges and build charts. The charts will show how much profit you have received from your past sales, and also show how much you will get if you sell your coins right now.
In this case, you need to build a server , place it somewhere, plan the architecture, choose an open source library for building diagrams, a test platform , etc.
It will take a lot of time to do something working.
Or you can write a small function that returns profits from a buy / sell operation and that can be run in Chrome DevTools.
In this case, you will get the desired value almost without any effort . It will also allow you to reuse a feature on a website that you may do in the future, or you will not.
You can also add a couple of console.log statements as a replacement for the “test platform”. This should be enough to make sure the function works. You can even build it with TDD!
If you still want to make the interface better, you do not need a server. You can create an HTML file with several text entries and run it locally from the file system.
If you really need to, start a static server and just copy the HTML.
The essay " Cathedral and Bazar " describes the use of iterative development in the OpenSource community. Here is an excerpt:
This principle ultimately found its place in the Agile Manifesto in the following form: "The highest priority is customer satisfaction, thanks to the regular and early delivery of valuable software."
If every time you start to solve a big task from the very beginning, without referring to step-by-step development, you will most likely be stuck. Even if you write code, it does not mean that you work productively and create value.
Instead of looking at a solution, look at the problem . Instead of looking at the answer, look at the question .
As engineers, we tend to see progress as the result of hard work. However, we need to work wisely.
This means that you need to program less and think more incrementally .
Make sure you don't start with the wrong wheel ... or miss your chance.
Fagner Brek believes that this happens because these projects did not implement the principles of continuous integration. In his note, the translation of which is in front of you, he writes that, in the case known to him, something needs to be done differently from the very beginning:
- Integrate your code changes into the work of everyone else as soon as possible, preferably several times a day.
- Program less, think more.
But how to do that? This is a fundamental question that everyone has to face in a software project: everything will change.
')
How can you continuously integrate a project every day if it takes months, not days, to complete it?
If all possible solutions to the problem do not lead to a viable option, the only alternative is to change the question.
Instead of asking “how to build a big project?”, You should ask: “how to divide a big project so that I can build the smallest useful piece?”
From the translator: the original article is devoted to the idea of Incremental Delivery , which we will call further iterative development , relying on Wikipedia in the most trivial way, since this does not contradict the ideas expressed in the article. If you prefer “incremental delivery”, then making a mental substitution will not be difficult.
The idea of ​​iterative development is to find different ways to solve the problem. It aims to realize a large project moving in small steps , rather than aiming directly at the ultimate goal.
The popular comic in the title picture illustrates this approach very well. In the upper example, which is entitled "How not to do," the user is not satisfied with all the steps except the last. In the bottom he is not satisfied with the first step, but starting from the second step, he likes it more and more. Moreover, the end result in the lower figure he likes much more than in the upper one.
But something in this comic is not entirely obvious.
In the first example, the result is a machine with a hard top. Because when a user ordered a car, he was married, and naturally, it would be desirable to have a closed car. However, somewhere in the middle of development, the user got divorced and changed his mind - he wanted a convertible.
The developers have already begun with the overall picture of the “ big project ”. The wheel was built specifically for this model, and there was no way to change anything in the middle of the process. The user received what he requested , although this is not what he wanted .
As a result, the user is just satisfied.
In the second example, the task was to make a tool to move quickly , and not just get a car, so it was possible to make changes to the plan throughout the process. The developers built a convertible in response to an unexpected end to the marriage. In the end, the user was able to change the wishes despite the fact that they differed from what he asked.
Another interpretation is possible: in the first case, the client receives exactly what he thought he wants. And in the second - he found out that he likes the wind, walking in his hair while riding a bicycle. Without an intermediate iteration, he would not have known.
Now he is happier.
The best way to work on something, the requirements for which can change, is to develop a minimum of what is needed right now, instead of considering what is needed later.
There is another non-obvious point.
In the first example, the construction of the car took 4 steps. However, in the lower example, it took 5 steps to come up with a convertible.
Actually, iterative development doesn't really make you “faster . ” If you define "speed" as the amount of code written in a certain time, iterative development may take even longer to complete the entire project.
However, if you consider “speed” as the sum of the value you received, then it is possible that you will need more time to do something, but less time to complete it. The trick is to build a minimal viable piece that can make the user happy, even if it is not the final big project.
What people want will change, and the initial request will become obsolete. Or, as I said before - everything will change.
The only thing that can be done is to accept this fact from the very beginning and plans accordingly.
Do not try to change the world, swim in the stream .
Iterative development struggles with the problem, but is not aimed at obtaining a previously described solution, and this allows you to work less and be faster.
In the convertible example, developers didn't need to know what the user wants. They simply worked on the problem of fast moving, and always in the right direction.
Note: you can argue that comics are a bad example that does not correspond to reality ... and you are right. In the comments to the original article, the author responds to such a remark.
Of course, in the real world, you need to be able to reuse all the components of the car, including the wheels, engine, gearbox and so on. If the wheels are not suitable for the convertible, then something definitely went wrong. That is, if you cannot use something made earlier, it will take a very long time to get a car at the last step of the second example. Ideally, you should reuse as much as you can from a previous product, not just knowledge and experience.
There are a number of different methods to achieve this, but this is not the topic of this article. In order to focus on the advantages of the iterative approach, it is necessary not to focus on the benefits of reuse. It's like when creating a map you need to sacrifice information to make it understandable.
The principle of iterative development can be applied to almost any area, and not just to the one with which the user interacts.
Programming some small pieces all the time, you can discover new information that can change your vision of a “big task”. It is also a way to avoid problems, when much more is done than was necessary , and to take into account changes in your own understanding of the problem.
Suppose you decide to participate in the universal cryptocurrency madness and have begun to make some buying / selling operations on several exchanges. However, these exchanges do not allow you to clearly view the profit / loss from your current and future sales. You can create a website.
The site will connect via API to the right exchanges and build charts. The charts will show how much profit you have received from your past sales, and also show how much you will get if you sell your coins right now.
In this case, you need to build a server , place it somewhere, plan the architecture, choose an open source library for building diagrams, a test platform , etc.
It will take a lot of time to do something working.
Or you can write a small function that returns profits from a buy / sell operation and that can be run in Chrome DevTools.
In this case, you will get the desired value almost without any effort . It will also allow you to reuse a feature on a website that you may do in the future, or you will not.
You can also add a couple of console.log statements as a replacement for the “test platform”. This should be enough to make sure the function works. You can even build it with TDD!
function profitFrom({ sell, buy }) { const profit = sell - buy; return (100 * profit / buy) + '%'; } console.log(`${profitFrom({ buy: 50, sell: 50 }) === '0%' && 'PASSED' || 'FAILED'}: No profit or loss for break even`); console.log(`${profitFrom({ buy: 50, sell: 100 }) === '100%' && 'PASSED' || 'FAILED'}: Profit`); console.log(`${profitFrom({ buy: 100, sell: 50 }) === '-50%' && 'PASSED' || 'FAILED'}: Loss`); If you still want to make the interface better, you do not need a server. You can create an HTML file with several text entries and run it locally from the file system.
If you really need to, start a static server and just copy the HTML.
You cannot build a bridge iteratively, but there are many ways to look at the problem of crossing the river.
The essay " Cathedral and Bazar " describes the use of iterative development in the OpenSource community. Here is an excerpt:
Linus treated his users as co-developers with maximum efficiency:
7. Release the product earlier. Release often. And listen to your customers.
This principle ultimately found its place in the Agile Manifesto in the following form: "The highest priority is customer satisfaction, thanks to the regular and early delivery of valuable software."
If every time you start to solve a big task from the very beginning, without referring to step-by-step development, you will most likely be stuck. Even if you write code, it does not mean that you work productively and create value.
Instead of looking at a solution, look at the problem . Instead of looking at the answer, look at the question .
As engineers, we tend to see progress as the result of hard work. However, we need to work wisely.
This means that you need to program less and think more incrementally .
Make sure you don't start with the wrong wheel ... or miss your chance.
If so, you have doubts about the correctness of the choice of wheels, we recommend professional conferences for those who do the Internet RHS ++ 2018 . Firstly, this is a mass of valuable information, it can be said on a platter, secondly, discussion zones and meetings, thirdly - the congress of activists , and just about 2,000 people, among whom you will definitely find those with whom you can discuss exactly your problems.
Source: https://habr.com/ru/post/352966/
All Articles