There is a polarity portrayed in this posting and the replies. I don't agree with, nor do I disagree with either pole. The original post makes an analogy between code as a product and a physical part as a product. Responders point out that the differences in the nature of the two products are so great that the analogy is of minimal value.

There is a great deal of difference in that it is fairly straight forward to measure the efficiency and effectiveness of the processing of metal parts. Those processes can be broken into sub-processes and further into process steps. Each step can be measured, and so can the results of each step.

That is very different from coding, true. There are of course process steps in producing functional code. Measuring the effectiveness and efficiency of the process and the end product is harder to do because there is little that is tangible....in most cases.

But code that diddles bits, changing data into information is not the only code that gets written out there in the real world. The machine shop is a good example. CNC, DNC, PLC... all of these have to have code written for them. It is not nice code like Perl either. Ladder logic is a PITA to write. And code like that does directly impact tangible products in very serious ways. It is not just scrap product that gets made, but the product that gets made that we don't realize is scrap that is dangerous, and often due to poorly written code that comes from poor development processes, poor specifications, poor understanding of the interface between the code and the real world.

The analogy made between the machinists and the coders is a bit of a stretch when is comes to measuring effectiveness and efficiency. The very real as compared the very abstract. There is however some middle ground in there that does bridge the two. A manufacturing execution system is a good example. It spans the abstract world of business decision making and the very real world of machine control systems. And at every level there is a boatload of code that exists to do more than make graphs and charts and reports and stick them on the corporate intranet. That code keeps millions of dollars worth of machinery and a good number of folks working safely and making safe product.

The nebulous nature of code is both its strength and its weakness. We can change it often and quickly. Not so with a 5 ton punch press, which is nice in a way, because with a 5 ton punch press you always know precisely what you have, and are not likely to change it much.

Perhaps the measurement of effectiveness and efficiency needs to be described in such a way that it encompasses both worlds.....

I am not stating this very clearly(because it is 01:00 and my grandson is keeping me up), but I appreciate the folks that posted here for what they have written. Made me start thinking...