Joel Spolsky: manufacturing inventories in software development
Imagine for a moment that you were at the bakery. At first, everything looks completely incomprehensible: a bunch of equipment of an unknown purpose, people are rushing around it. Then you learn a little and notice simpler and more familiar things. Here are the sesame containers. Here are the big vats of dough. Here are the little balls of this dough. Already baked buns.
All this is production stocks, raw materials or semi-finished products that need to be turned into the final product and sold in order to make a profit. Stocks move and accumulate between machines. Next to the machine, sprinkled with sesame buns for hamburgers is a container with this same sesame. At the very end of the conveyor are boxes of ready-made bread and rolls waiting to be loaded onto trucks that will take them to hungry consumers.
Stockpiling is worth the money. Suppose that there are six 50-ton silos at the bakery for storing flour. This means that, on average, about 150 tons of flour are found in them every day. At today's prices, it is $ 73,000 of dead capital.
')
There are other costs, such as damage. Flour can be stored for months, but ready-made buns begin to lose in price as soon as they leave the oven; after 24 hours they cost almost nothing.
Why, then, to keep stocks at all? Then there is also the cost associated with their lack. If it takes two days to order a new batch of sesame buns, then if they end up in your diner, your hamburger business will stop for two days. Stocks are a buffer that prevents unanticipated stops. Now a lot of algorythms have been invented to calculate the optimal volume of these buffers (for a start: lean manufacturing , the theory of constraints ).
Why am I telling you all this? Then, in the production of software, there are also places where "production stocks" accumulate. And storing these stocks can cost a lot of time and money.
"What? Is it possible to compare the production of software and buns? ”- you ask.
Think of ideas as raw and semi-finished products. As well as dough pieces, ideas pass through several processing points before being presented to the end user as product functions:
(PS "Waterfall" has nothing to do with it. No. No, absolutely not! Roll off!)
Stocks can accumulate between all these stages. For example, when a programmer finishes writing code (step 3), he sends it to the tester (step 4). At any given time, some amount of code is waiting for its turn for testing. These are stocks.
The cost of such reserves is huge. They can add six or even twelve months to the time of release. All this time a lot of code and ideas have been idle at different stages of production instead of falling into the hands of users. These delays can be a decisive difference between an innovative product (iPhone) and an eternally second catch-up analog (Windows Phone). It’s almost impossible to force a consumer to buy Windows Phone if the iPhone was only six months old.
In many markets, the network effect works, and to be the first is to become the winner who gets everything. So the size of stocks at the development stage can be crucial.
Let's go through the three places where most stocks accumulate.
Backlog Ideas of new features are swarming around each project, and they appear much faster than they can be implemented. Therefore, they are written to the implementation queue - backlog. A lot of ideas in backlog are really worthless and are recorded only in order not to offend those who came up with them. As a result, everyone is happy.
The problem is that 90% of backlog features will never be implemented. So every minute spent writing, designing, thinking about or discussing such features is a waste of time. When I hear that some teams practice regular “scratching backlog”, carefully and methodically wasting precious time on things that will never become part of the final product, I want to snatch my eyes.
Suggestion: Do not allow backlog to grow more than a month or other work. If the backlog is full, do not add new elements there until you implement the old ones. No need to spend time discussing, designing or specifying features from backlog. It should be viewed as a list of things that are forbidden to talk about and that it is forbidden to work on before the start of implementation.
Bug trackers. This is a great thing. Especially if the bug reports are detailed, complete and specific. But I noticed that in the real world, the desire not to miss a single error message leads to the fact that once you are horrified to find that there are 3000 unclosed errors in your tracker, some of which have long lost their relevance, others cannot be reproduced, and most not worth fixing them because they are completely insignificant. It took months and years to collect these bug reports, and you ask yourself how it is generally possible - we have 3000 errors, and the product is obviously very good, users love it and use it every day? And it becomes clear to you that you simply over-diligently collected these errors, instead of developing a product.
Suggestions:
Features waiting to be released. Until now, many teams are working quarterly or annual release cycles of versions, usually if the process of deploying a new version is difficult and expensive. Operating systems and any other software that users must install themselves fall into this category.
This is one of the most expensive forms of reserves. They could bring you money, but they are just gathering dust while waiting for a release, and in the meantime the product of more nimble competitors is already doing it!
The worst thing is that developers often do not even feel the destructive effect of such delays, since the whole team sits on nightly assemblies and uses new features every day. For sure, Microsoft is terribly happy with Windows 8, which they have been using for a year now, so they don’t understand the suffering of OEMs who are trying to sell computers with Windows 7 in the world of Mac OS X Lion.
Proposal: Do not let the ready-made functional lie dead weight. Redesign your deployment process to update every few months, not years. If you have already done this, try to be updated weekly. Raise the bar higher and roll out small changes as often as possible.
So what am I leading to? We at Fog Creek had all three types of stocks: a giant backlog, a monstrous base of bug reports and features waiting to be released for years. We felt all this the hard way. And I realized that we need a system that would limit the size of stocks.
At first, I came up with the thing I called “Five Things”. The idea was that the project management program would allow everyone to answer no more than five things - two in work, one on the way and a couple more - in plans for the near future. In this form, the idea was never implemented, but it formed the basis of Trello .
Trello works great with a small amount of stock, but it quickly becomes cumbersome and uncomfortable when you cram a lot of excess into it. This is intentional. This allows you to see and feel when stocks are too much. (click on the screenshot and look at our own development page).
Every day you look at the Trello board and see, for example, that as many as 17 features are ready and waiting for release. This encourages the elimination of the mash as soon as possible.
Every time someone offers a crazy new idea, you look into the backlog and, if there are too many entries, do not waste time discussing and thinking about this idea.
I sincerely hope that this approach will allow you to spend much less time working on things that will never see the white light. Scratching backlog. What nonsense!
All this is production stocks, raw materials or semi-finished products that need to be turned into the final product and sold in order to make a profit. Stocks move and accumulate between machines. Next to the machine, sprinkled with sesame buns for hamburgers is a container with this same sesame. At the very end of the conveyor are boxes of ready-made bread and rolls waiting to be loaded onto trucks that will take them to hungry consumers.
Stockpiling is worth the money. Suppose that there are six 50-ton silos at the bakery for storing flour. This means that, on average, about 150 tons of flour are found in them every day. At today's prices, it is $ 73,000 of dead capital.
')
There are other costs, such as damage. Flour can be stored for months, but ready-made buns begin to lose in price as soon as they leave the oven; after 24 hours they cost almost nothing.
Why, then, to keep stocks at all? Then there is also the cost associated with their lack. If it takes two days to order a new batch of sesame buns, then if they end up in your diner, your hamburger business will stop for two days. Stocks are a buffer that prevents unanticipated stops. Now a lot of algorythms have been invented to calculate the optimal volume of these buffers (for a start: lean manufacturing , the theory of constraints ).
Why am I telling you all this? Then, in the production of software, there are also places where "production stocks" accumulate. And storing these stocks can cost a lot of time and money.
"What? Is it possible to compare the production of software and buns? ”- you ask.
Think of ideas as raw and semi-finished products. As well as dough pieces, ideas pass through several processing points before being presented to the end user as product functions:
- Making decisions (should we implement this function?)
- Design (specifications, planning, layouts, etc.)
- Implementation (writing code)
- Testing (search for errors)
- Debugging (error correction)
- Release (delivery of the program to consumers, deployment on the server)
(PS "Waterfall" has nothing to do with it. No. No, absolutely not! Roll off!)
Stocks can accumulate between all these stages. For example, when a programmer finishes writing code (step 3), he sends it to the tester (step 4). At any given time, some amount of code is waiting for its turn for testing. These are stocks.
The cost of such reserves is huge. They can add six or even twelve months to the time of release. All this time a lot of code and ideas have been idle at different stages of production instead of falling into the hands of users. These delays can be a decisive difference between an innovative product (iPhone) and an eternally second catch-up analog (Windows Phone). It’s almost impossible to force a consumer to buy Windows Phone if the iPhone was only six months old.
In many markets, the network effect works, and to be the first is to become the winner who gets everything. So the size of stocks at the development stage can be crucial.
Let's go through the three places where most stocks accumulate.
Backlog Ideas of new features are swarming around each project, and they appear much faster than they can be implemented. Therefore, they are written to the implementation queue - backlog. A lot of ideas in backlog are really worthless and are recorded only in order not to offend those who came up with them. As a result, everyone is happy.
The problem is that 90% of backlog features will never be implemented. So every minute spent writing, designing, thinking about or discussing such features is a waste of time. When I hear that some teams practice regular “scratching backlog”, carefully and methodically wasting precious time on things that will never become part of the final product, I want to snatch my eyes.
Suggestion: Do not allow backlog to grow more than a month or other work. If the backlog is full, do not add new elements there until you implement the old ones. No need to spend time discussing, designing or specifying features from backlog. It should be viewed as a list of things that are forbidden to talk about and that it is forbidden to work on before the start of implementation.
Bug trackers. This is a great thing. Especially if the bug reports are detailed, complete and specific. But I noticed that in the real world, the desire not to miss a single error message leads to the fact that once you are horrified to find that there are 3000 unclosed errors in your tracker, some of which have long lost their relevance, others cannot be reproduced, and most not worth fixing them because they are completely insignificant. It took months and years to collect these bug reports, and you ask yourself how it is generally possible - we have 3000 errors, and the product is obviously very good, users love it and use it every day? And it becomes clear to you that you simply over-diligently collected these errors, instead of developing a product.
Suggestions:
- Immediately weed out errors that are too small to write them down.
- Make sure that at any time the time to correct all errors from the bug tracker does not exceed two weeks.
- If there are more of them, stop and start correcting them until you get to openly stupid and minor errors. After that, close them all with the mark “won't fix”. Do not be afraid to miss something important - serious mistakes will surely come up more than once.
Features waiting to be released. Until now, many teams are working quarterly or annual release cycles of versions, usually if the process of deploying a new version is difficult and expensive. Operating systems and any other software that users must install themselves fall into this category.
This is one of the most expensive forms of reserves. They could bring you money, but they are just gathering dust while waiting for a release, and in the meantime the product of more nimble competitors is already doing it!
The worst thing is that developers often do not even feel the destructive effect of such delays, since the whole team sits on nightly assemblies and uses new features every day. For sure, Microsoft is terribly happy with Windows 8, which they have been using for a year now, so they don’t understand the suffering of OEMs who are trying to sell computers with Windows 7 in the world of Mac OS X Lion.
Proposal: Do not let the ready-made functional lie dead weight. Redesign your deployment process to update every few months, not years. If you have already done this, try to be updated weekly. Raise the bar higher and roll out small changes as often as possible.
So what am I leading to? We at Fog Creek had all three types of stocks: a giant backlog, a monstrous base of bug reports and features waiting to be released for years. We felt all this the hard way. And I realized that we need a system that would limit the size of stocks.
At first, I came up with the thing I called “Five Things”. The idea was that the project management program would allow everyone to answer no more than five things - two in work, one on the way and a couple more - in plans for the near future. In this form, the idea was never implemented, but it formed the basis of Trello .
Trello works great with a small amount of stock, but it quickly becomes cumbersome and uncomfortable when you cram a lot of excess into it. This is intentional. This allows you to see and feel when stocks are too much. (click on the screenshot and look at our own development page).
Every day you look at the Trello board and see, for example, that as many as 17 features are ready and waiting for release. This encourages the elimination of the mash as soon as possible.
Every time someone offers a crazy new idea, you look into the backlog and, if there are too many entries, do not waste time discussing and thinking about this idea.
I sincerely hope that this approach will allow you to spend much less time working on things that will never see the white light. Scratching backlog. What nonsense!
Source: https://habr.com/ru/post/147501/
All Articles