[awesome_dude]

Just for the record, those have intangible results. They improve maintainability, reduce vectors for bugs (which are always based on misunderstandings) and increase velocity.

Absolutely none of those can be measured (hence intangible) which is why they are a hard sell

[creer]

> Absolutely none of those can be measured

They can be estimated (with a wild range) and that's still useful: If that impact is clearly in the noise, drop it. If that impact is clearly huuuge then set up some ongoing measurements and get started step-wise and demonstrate results. If you think you need to rebuild the whole thing before seeing any results, you see the world in a way that won't happen (except if your business is not delivering solutions but is selling solutions - in which case carry on). That doesn't mean the ground idea is incorrect.

[awesome_dude]

Can you demonstrate, or show how that would work (serious question)

[creer]

Sure. Let's take that idea:

> reduce vectors for bugs (which are always based on misunderstandings)

Is that really impossible to measure? (For cheap that is. Cheap measure, cheap estimate, cheap confidence). Is that really impossible to monitor?

Grab a random sample of 100 fixed bugs in the past 2 years. Go through them one by one. How many do you really seriously think would have been avoided? If it's not much more work, give it some weighting on confidence and impact or something. For how much addl work? Once you notice what you could count, restart from the top (re-randomize?) - it's only 100 bugs. Is it really 100%, or is it now that are looking at the data more like 10% at best? Was it really impossible to get data?

Now that you have an estimate, write it up and circulate it - It's risky: you could be volunteered to fix the problem and maybe you don't want that.

Would it really be impossible to monitor over the next year? (Still cheap data, cheap results - except if you really estimated 100% because now you were able to get real budget - even if too small - to attack it.)

Estimates, targets, budgets, deadlines are all different concepts. A fraught but carefully worked up estimate is rarely impossible.

Entire businesses get founded and funded on "impossible" estimates.

[awesome_dude]

Ah, I think that I get that, thanks.

Although to be clear, the estimates will "this is where we think that we will be saving money"

followed by a review (in 12 months time) that will be "this is what we think is the result, but it will include improvements from other vectors, such as better communication from business"

[creer]

Sure. This is rough engineering. If you identify a plausible significant cause, and you attack that, and you get useful improvement, people are not too likely to be overly concerned that there was some confounding factor in the improvement. If there is any excess, it's likely to be in the other direction: deciding that the likely improvement is not worth it. Engineers hate that kind of decision.

[awesome_dude]

We're really still no better off than where we started at - it cannot be measured, it has to be estimated, the estimates are only able to be validated after some time period has elapsed (1 - 5 years) and the confounding factors cannot be discounted.

I'm not arguing that we shouldn't I'm arguing that the business cannot put a number on it that it can rely on. That's fine if the budget is available, but if there's no budget, almost always for reasons beyond the engineer's responsibility (VC money, market resizing, etc) then you're really struggling to be able to justify it.