3 ms·

Is anyone going to seriously talk about how we can treat code as inventory? How can we continuously reduce inventory? His idea around three month time based

by fouc 8y ago

Is anyone going to seriously talk about how we can treat code as inventory? How can we continuously reduce inventory? His idea around three month time based decay on code doesn't seem that feasible to me. Perhaps what we need is a fixed complexity (LOC and other metrics) target where we're not allowed to exceed that unless specific reasons come up. 100% code coverage is probably another thing that might help reduce dead inventory. We also can measure what code actually gets used in production, and delete anything not being used. Could even automatically delete code based on lack of usage, and even delete the corresponding tests.

ellius 8y ago
I think the problem is that "code" straddles this very thin line between technology and operations. The value of technology is that you can solve a problem and perform it more effectively essentially indefinitely. Operations are much more fluid; the most effective way to run operations changes constantly and evolves over time. I think a lot of our time is wasted trying to capture operational logic that is unlikely to persist over long periods of time, and that's where some sort of code decay mechanism would he useful. But the flip side is that occasionally your code will encapsulate something more technological, a solution that addresses a core function of your business or whatever other problem space, and then you have code that you absolutely 100% do not want to decay. I'm not sure there's any clear mechanism to distinguish between those two things. Your idea of scanning code that runs in production might be a good place to start, but plenty of pseudo-dead code (logic that ought to be decayed but manages to run anyway) will probably continue to accrue.
KMag 8y ago
That once-a-quarter rare bug handling code is not going to fare well with automatic deletion of code that doesn't get exercised in production. In some domains, I've heard of up to half the code being code that handles rare conditions. More importantly than removing mature code, it seems to me that pieces of code that are in use and haven't changed in a while are good candidates for applying formal methods.
kasey_junk 8y ago
When I was a new developer it was all the rage to use static analysis tools to calculate cyclomatic complexity. There were even processes that required justifying branches. Unsurprisingly people just turned to patterns that masked the cyclomatic complexity from the tools.
solatic 8y ago
It's only really fair to think of code which is tied to features or bugfixes which haven't been released yet. The reason why inventory is a problem in Lean is because it represents spend that hasn't been repaid with revenue, once you ship the code then it's shipped. Within the Lean model, I think it makes more sense to think of code as something that "weighs down" the different stations in the factory, making them less efficient, like unmaintained workstations in a factory that slowly break down. If you have a station in your software factory representing API changes, then whether or not you have a pile of half-completed work waiting for API changes has little to do with how quickly you can make changes to the API - that's determined by how many changes you've made before. It's much easier to delete code if you're allowed to delete features. And it's much easier to delete features if you have a clear deprecation and EOL policy, an easy way for customers to determine if they're affected, and simple means of migration.

by fouc 8y ago

ellius 8y ago

I think the problem is that "code" straddles this very thin line between technology and operations. The value of technology is that you can solve a problem and perform it more effectively essentially indefinitely. Operations are much more fluid; the most effective way to run operations changes constantly and evolves over time. I think a lot of our time is wasted trying to capture operational logic that is unlikely to persist over long periods of time, and that's where some sort of code decay mechanism would he useful. But the flip side is that occasionally your code will encapsulate something more technological, a solution that addresses a core function of your business or whatever other problem space, and then you have code that you absolutely 100% do not want to decay. I'm not sure there's any clear mechanism to distinguish between those two things. Your idea of scanning code that runs in production might be a good place to start, but plenty of pseudo-dead code (logic that ought to be decayed but manages to run anyway) will probably continue to accrue.

KMag 8y ago

That once-a-quarter rare bug handling code is not going to fare well with automatic deletion of code that doesn't get exercised in production. In some domains, I've heard of up to half the code being code that handles rare conditions. More importantly than removing mature code, it seems to me that pieces of code that are in use and haven't changed in a while are good candidates for applying formal methods.

kasey_junk 8y ago

When I was a new developer it was all the rage to use static analysis tools to calculate cyclomatic complexity. There were even processes that required justifying branches. Unsurprisingly people just turned to patterns that masked the cyclomatic complexity from the tools.

solatic 8y ago

It's only really fair to think of code which is tied to features or bugfixes which haven't been released yet. The reason why inventory is a problem in Lean is because it represents spend that hasn't been repaid with revenue, once you ship the code then it's shipped. Within the Lean model, I think it makes more sense to think of code as something that "weighs down" the different stations in the factory, making them less efficient, like unmaintained workstations in a factory that slowly break down. If you have a station in your software factory representing API changes, then whether or not you have a pile of half-completed work waiting for API changes has little to do with how quickly you can make changes to the API - that's determined by how many changes you've made before. It's much easier to delete code if you're allowed to delete features. And it's much easier to delete features if you have a clear deprecation and EOL policy, an easy way for customers to determine if they're affected, and simple means of migration.