{"id":858,"date":"2012-07-09T00:14:19","date_gmt":"2012-07-09T00:14:19","guid":{"rendered":"https:\/\/www.joelonsoftware.com\/?p=858"},"modified":"2012-07-09T00:14:19","modified_gmt":"2012-07-09T00:14:19","slug":"software-inventory","status":"publish","type":"post","link":"https:\/\/www.joelonsoftware.com\/2012\/07\/09\/software-inventory\/","title":{"rendered":"Software Inventory"},"content":{"rendered":"

Imagine, for a moment, that you came upon a bread factory for the first time. At first it just looks like a jumble of incomprehensible machinery with a few people buzzing around. As your eyes adjust you start to see little piles of things that you do<\/em> understand. Buckets of sesame seeds. Big vats of dough. Little balls of dough. Baked loaves of bread.<\/p>\n

Those things are inventory. Inventory tends to pile up between machines. Next to the machine where sesame seeds are applied to hamburger buns, there\u2019s a big vat of…sesame seeds. At the very end of the assembly line, there are boxes and boxes of bread, waiting for trucks to drive them off to customers.<\/p>\n

Keeping inventory costs money. Suppose your bakery has six 50-ton silos to store flour. Whenever they empty out, you fill them up. That means on the average day you have 150 metric tons of wheat flour in stock. At today\u2019s prices, you\u2019ve tied up $73,000. Forever.<\/p>\n

Inventory may have other costs too, like spoilage. Flour lasts for months, but the minute bread comes out of the oven it starts dropping in value; after 24 hours it\u2019s nearly worthless.<\/p>\n

\"\"<\/a><\/span>Why keep inventory at all? Because there are costs associated with running out of things, too. If sesame seeds take two days to order, and you run out of sesame seeds, you are out of the hamburger bun business for two days. Inventory provides a buffer that prevents any part of the process from stalling. There are modern algorithms to optimize how much buffer you need at every point (read up on Toyota\u2019s lean production system and the Theory of Constraints to get started).<\/p>\n

Why do I care about any of this? The software production process has several major \u201cinventory\u201d accumulation points, itself. Stuff accumulates at those points and ends up wasting a lot of time and money.<\/p>\n

\u201cWhat? How is software like a factory?\u201d you ask.<\/p>\n

Think of product ideas as the raw material. Depending on your process, product ideas may go through several assembly line points before they are delivered as finished features to the customer:<\/p>\n

    \n
  1. A decision-making process (should we implement this feature?)<\/li>\n
  2. A design process (specs, whiteboards, mockups, etc)<\/li>\n
  3. An implementation process (writing code)<\/li>\n
  4. A testing process (finding bugs)<\/li>\n
  5. A debugging process (fixing bugs)<\/li>\n
  6. A deployment process (sending code to customers, putting it on web server, etc)<\/li>\n<\/ol>\n

    (PS No, this is not \u201cwaterfall.\u201d No it isn\u2019t. Is not. <\/em>Shut up.)<\/p>\n

    In between each of these stages, inventory can pile up. For example, when a programmer finishes implementing their code (stage 3) they give it to a tester to check (stage 4). At any given time, there is a certain amount of code waiting to be tested. That code is inventory.<\/p>\n

    The \u201ccost\u201d of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers\u2019 hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone). It\u2019s nearly impossible to get people to buy Windows Phones, even if the iPhone is only six months better. A lot of markets have network effects, and being first has winner-take-all implications. So getting rid of inventory in the development process can make or break a product.<\/p>\n

    Let\u2019s go over the three places most inventory accumulates.<\/p>\n

    Feature backlogs.<\/strong> Every product attracts new feature ideas, and you can\u2019t implement ideas as fast as you can think them up, so you write them down, and this list is called the feature backlog. A lot of the ideas on the backlog are bad ideas, and you merely wrote them down to avoid hurting the feelings of the people who thought them up. Backlogs make everyone feel good. <\/p>\n

    The trouble is that 90% of the things in the feature backlog will never get implemented, ever. So every minute you spent writing down, designing, thinking about, or discussing features that are never going to get implemented is just time wasted. When I hear about product teams that regularly have \u201cbacklog grooming\u201d sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.<\/p>\n