Not exactly. What people pay for water should be uniform and proportional to the cost of providing it. I am not a fan of influencing behavior through taxation and subsidy. That is itself wasteful and inefficient.
You don't even need to have bracketed, progressively higher rates for water use. It would be enough to just stop subsidizing those who use the most.
Less than 1% of human-used freshwater in the US goes through toilets.
Personally, I don't bother to optimize code unless the profiler says it is heavily used. I am probably not going to mess with a routine that only accounts for 1% of execution until well after I have optimized the hell out of the two functions that collectively account for 80% of CPU time. (Analogy-wise, that's power plants and irrigation.)
Of course, given enough developers, someone will eventually have to optimize out at the edges. There's no reason to say we can't tackle toilets at the same time as pivot irrigators; it's just that any work done on them will be inherently less valuable. You're not going to need your best people on it. And any gains will be small.
It isn't entirely about improving performance at that point. Anything I do to shave microseconds from that 1%-used function is likely to introduce additional bugs into the code--such as failures in one of the two major use cases for it. (Poop remains in the bowl after I flush.) That's not so bad if I set up unit tests beforehand, because I then know when I have broken something.
But where are your unit tests for toilet flushing, Mr. Legislator? Nowhere. They don't bother with the profiler or with unit tests. So they end up with shitty code.
You don't even need to have bracketed, progressively higher rates for water use. It would be enough to just stop subsidizing those who use the most.
Less than 1% of human-used freshwater in the US goes through toilets.
Personally, I don't bother to optimize code unless the profiler says it is heavily used. I am probably not going to mess with a routine that only accounts for 1% of execution until well after I have optimized the hell out of the two functions that collectively account for 80% of CPU time. (Analogy-wise, that's power plants and irrigation.)
Of course, given enough developers, someone will eventually have to optimize out at the edges. There's no reason to say we can't tackle toilets at the same time as pivot irrigators; it's just that any work done on them will be inherently less valuable. You're not going to need your best people on it. And any gains will be small.
It isn't entirely about improving performance at that point. Anything I do to shave microseconds from that 1%-used function is likely to introduce additional bugs into the code--such as failures in one of the two major use cases for it. (Poop remains in the bowl after I flush.) That's not so bad if I set up unit tests beforehand, because I then know when I have broken something.
But where are your unit tests for toilet flushing, Mr. Legislator? Nowhere. They don't bother with the profiler or with unit tests. So they end up with shitty code.