Inventory in software

I’ve been thinking a bit about all these factory references that occur when discussing software development. So here is an inventory management view, I guess.

Inventory, viewed from a lean perspective is waste. If you can keep your process running with minimal inventory, then you can decrease costs for changing the process.

Software is immaterial, so there is no “inventory” per se. But, there are equivalent cost scenarios.

Here are a few examples of inventories that occur during software development:

• Documentation
• Versions of the same software in production
• Source-code
• Issue tracking systems

I’ll describe the cost scenarios for these examples, there is probably more.

Documentation

As soon as you write your documentation, it starts aging. Documentation, be it help documents or documents describing the system, are like groceries. They go old, and they do so in different rates. Some documentation is more resistant to change while other gets outdate faster than you can write it. This implies a maintenance cost for documentation, either keep it up to date or throw it out. The cost of someone using old documentation could be very expensive.

Versions of the same software in production

A favorite of mine. Every version you have in production has its own personality, it’s own quirks, features, bugs and what not. This implies greatly increased support costs.

Source-code

Source-code is also a sort of inventory. The more code there is the more there is to maintain. Sure you might not change the code all that often, but unless your code is separate products, it interacts. Larger code-bases require more testing (be it automated or manual testing). Good design helps reduce the size of the code base, and from a cost perspective keeping the codebase low is  very important.

Issue tracking systems

Issue tracking systems is just an inventory of reported issues. As it grows the cost for maintaining the issues grows. Every release has the potential to solve any issue, which could at worst imply workload on developers to keep, not only the source-code and documentation up to date, but also the issue tracking system. Secondly, if it takes too long between something being entered into the tracking system and it being fixed. Then the people, stakeholders, for that issue have forgotten about it or worked around it in some way. Also most of the time, the act of managing and tracking the issue costs far more than just fixing it.

Reducing inventory

So what to strive for, only keep documentation for which you commit to writing and maintaining. Have one version of the system in production, and get mechanisms into place to quickly update all clients so you can keep it so. Keep your code-base small, strive to solve problems using better design and less code. Think more, code less. Last but not least, fix problems as they occur, strive for zero-defects. If your using Scrum you can handle issues in a sprint, but avoid long-running tracking.