So the janitor should analyse and quantify what difference he will make to the companies bottom line before he wipes those skidmarks off?

Not everything is quantifiable like that. If I'm writing code and I take the time to make it 30% faster then it won't make a difference to our bottom line. If that's done everywhere then customers will like us more, be more likely to stay with us and be more likely to recommend us, but that can't be quantified in my day to day work.

Probably the biggest change looming over our industry is coding to - and deployment on - platforms that definitely are instrumented to capture exactly how much value a developer is adding (or subtracting) from the bottom line with every commit (it's a natural outgrowth of Function As A Service architectures).

It is already possible to more-or-less show how a code change (bug/fix, new feature, change in storage backend, etc.) directly affects your IAAS bill at the end of each month, and taking it a step further by tying in some instrumentation and formulas (of the sort often used to calculate the effectiveness of marketing funnels for optimization and A/B testing) to show the concomittant effect on revenue allows ROI to be calculated.

So, I am pretty sure that Finance-Oriented Programming is going to be a thing not so many years from now, tied into the whole toolchain, and very few - not developers nor their managers - seem prepared for that sea-change (some Operations folks are probably a bit better off in terms of mindset and processes).