Program less, think more ... incrementally
- Transfer
Unfortunately, examples of projects for which developers have spent a lot of time, say more than six months, but have never been published, are not uncommon.
Fagner Breck believes that this is 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 a 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 a project be continuously integrated every day if it takes months, not days, to complete it?
Instead of asking “how to build a large project?”, You should ask: “how to divide a large project so that I can build the smallest useful piece?”
The idea of iterative development is to find various ways to solve the problem. It aims to implement a large project moving in small steps , rather than aiming immediately 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 it,” the user is dissatisfied with all the steps except the last. In the bottom, he is unhappy only in the first step, but starting from the second step he likes more and more. Moreover, he likes the final result in the lower figure much more than in the upper one.
But something in this comic is not entirely obvious.
In the first example, the result is a hard top car. Because when a user ordered a car, he was married, and naturally, he wanted 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 big 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 simply satisfied.
In the second example, the task was to make a tool for quick movement, 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 the unexpected end of the marriage. In the end, the user was given the opportunity to change the wishes despite the fact that they were different from what he requested.
Now he is happier.
There is another unobvious moment.
In the first example, building a car took 4 steps. However, in the bottom example, it took 5 steps to come up with a convertible.
In fact, iterative development does not really make you “faster . ” If you define “speed” as the amount of code written over a given time, iterative development can take even longer to complete the entire project.
However, if you consider “speed” as the sum of the value you have received, then it is possible that you will need more time to do something, but less time to finish it. The trick is to build a minimal viable piece, which can make the user happy, even if this 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 make plans accordingly.
Do not try to change the world, swim in the stream .
In the convertible example, developers did not need to know what the user wants. They simply worked on the problem of fast movement, and always in the right direction.
Note: you can argue that the comic book is a bad example that does not correspond to reality ... and you are right. In the comments on the original article, the author gives an answer to such a remark.
The principle of iterative development can be applied to almost any field, and not just to the one with which the user interacts.
While programming some small pieces, you can discover new information that can change your vision of the “big task”. It is also a way to avoid a problem when substantially more has been done than was necessary , and to take into account changes in your own understanding of the problem.
Suppose you decide to participate in a universal cryptocurrency madness and begin to make some buy / sell 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 necessary exchanges and build diagrams. 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 will return the profit from the purchase / sale operation and which can be launched in Chrome DevTools.
In this case, you will get the desired value almostwithout any effort . It will also allow you to reuse a feature on a website that you may or may not do in the future.
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 multiple text inputs 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 Bazaar " talks about using iterative development in the OpenSource community. Here is an excerpt:
This principle ultimately found its place in the Agile manifest in this form: "The highest priority is customer satisfaction, through the regular and early delivery of valuable software."
If every time you start to solve a big problem from the very beginning, not referring to step-by-step development, you will most likely get stuck. Even if you write code, this does not mean that you work productively and create value.
Instead of looking at the solution, look at the problem . Instead of looking at the answer, look at the question .
As engineers, we tend to understand progress as the result of hard work. However, we need to work wisely.
And this means that you need to program less and think more incrementally .
Make sure you don't start from the wrong wheel ... or miss your chance.
Fagner Breck believes that this is 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 a 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 a project be continuously integrated 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 large project?”, You should ask: “how to divide a large project so that I can build the smallest useful piece?”
From a translator: the original article is devoted to the idea of Incremental Delivery , which we will later call iterative development , relying on wikipedia in the most trivial way , since this does not contradict the ideas expressed in the article. If you prefer the “incremental delivery”, it will not be difficult to make a mental replacement.
The idea of iterative development is to find various ways to solve the problem. It aims to implement a large project moving in small steps , rather than aiming immediately 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 it,” the user is dissatisfied with all the steps except the last. In the bottom, he is unhappy only in the first step, but starting from the second step he likes more and more. Moreover, he likes the final result in the lower figure much more than in the upper one.
But something in this comic is not entirely obvious.
In the first example, the result is a hard top car. Because when a user ordered a car, he was married, and naturally, he wanted 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 big 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 simply satisfied.
In the second example, the task was to make a tool for quick movement, 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 the unexpected end of the marriage. In the end, the user was given the opportunity to change the wishes despite the fact that they were different from what he requested.
Another interpretation is also possible: in the first case, the client receives exactly what he thought he wanted. 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 it.
Now he is happier.
The best way to work on something, the requirements for which can change, is to develop a minimum of what you need right now, instead of thinking about what will be needed later.
There is another unobvious moment.
In the first example, building a car took 4 steps. However, in the bottom example, it took 5 steps to come up with a convertible.
In fact, iterative development does not really make you “faster . ” If you define “speed” as the amount of code written over a given time, iterative development can take even longer to complete the entire project.
However, if you consider “speed” as the sum of the value you have received, then it is possible that you will need more time to do something, but less time to finish it. The trick is to build a minimal viable piece, which can make the user happy, even if this 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 make 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 did not need to know what the user wants. They simply worked on the problem of fast movement, and always in the right direction.
Note: you can argue that the comic book is a bad example that does not correspond to reality ... and you are right. In the comments on the original article, the author gives an answer to such a remark.
Of course, in the real world, you must be able to reuse all the components of the car, including wheels, engine, gearbox and more. If the wheels are not suitable for a convertible, then something definitely went wrong. That is, if you can’t use something done earlier, it will take a very long time to get the car in the last step of the second example. Ideally, you should reuse as much as you can from the previous product, not just knowledge and experience.
There are a variety of different methods to achieve this, but this is not the topic of this article. In order to focus on the benefits of the iterative approach, one has not to focus on the benefits of reuse. It’s like when creating a map you need to sacrifice informationto make it understandable.
The principle of iterative development can be applied to almost any field, and not just to the one with which the user interacts.
While programming some small pieces, you can discover new information that can change your vision of the “big task”. It is also a way to avoid a problem when substantially more has been done than was necessary , and to take into account changes in your own understanding of the problem.
Suppose you decide to participate in a universal cryptocurrency madness and begin to make some buy / sell 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 necessary exchanges and build diagrams. 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 will return the profit from the purchase / sale operation and which can be launched in Chrome DevTools.
In this case, you will get the desired value almostwithout any effort . It will also allow you to reuse a feature on a website that you may or may not do in the future.
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 multiple text inputs 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 a river.
The essay " Cathedral and Bazaar " talks about using 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 manifest in this form: "The highest priority is customer satisfaction, through the regular and early delivery of valuable software."
If every time you start to solve a big problem from the very beginning, not referring to step-by-step development, you will most likely get stuck. Even if you write code, this does not mean that you work productively and create value.
Instead of looking at the solution, look at the problem . Instead of looking at the answer, look at the question .
As engineers, we tend to understand progress as the result of hard work. However, we need to work wisely.
And this means that you need to program less and think more incrementally .
Make sure you don't start from the wrong wheel ... or miss your chance.
If doubts are gnawing you about the correct choice of a wheel, we recommend professional conferences for those who make Internet RIT ++ 2018 . Firstly, this is a lot of valuable information, it can be said on a silver platter, secondly, discussion zones and meetings, thirdly, a congress of activists , and just about 2,000 people, among whom there are certainly people with whom you can discuss your problems.