Your Call Water Series – Feedback

waterfall into pond

Subject: Your Call Water Series - Feedback

This is in response to: “Your Call Water Series” [webcitation] radio program on KALW, 91.7 in San Francisco.

I’ve listened a few of your programs on water. There have been mentions about learning from other communities and countries. Most of the focus seems to be on “big solutions,” but water cycles happen at global, regional, and local levels. We need solutions that address the problems at all these different levels.

Of course, there is a need for large water projects, to move water to large cities. But the large projects will not solve the water problem if the “small water cycles” are not addressed. Those cycles need to be addressed at more local levels. For example, water-retention landscaping methods can revitalize areas where the water and land have been abused.

Ground water depletion is talked about as if groundwater is a limited resource. In some ways it is, but it’s not the sort of resource one can hoard. “Mainstream” water management attempts to limit reservoir evaporation and seepage into the ground as if those things were bad. That is backward. Water needs to evaporate, so it can return as rain. Water needs to seep into the ground so that it can feed life and be purified by life and the ground. In contrast, water retention landscaping techniques use small reservoirs in order to slow down water runoff, so that water has time to seep into the ground.

From what I’ve heard about the California Ground Water Law, the focus is on limiting groundwater use, i.e. limiting the amount of water being removed. Words like “sustainable” are used, but there is almost nothing said about practices that get more water back into the ground. Not only are we taking out water faster than it is going back in, we are prioritizing practices designed to prevent water from going back into the ground. By focusing only on limiting water extraction, only half the problem is being addressed.

Continue reading Your Call Water Series – Feedback


Planned Obsolescence in Software


“Fast, Cheap, Good – pick two!”

In any software project (or probably any project where you are creating something), you cannot lock down all three of these dimensions–i.e., you cannot define what you want for all of them. If you are very experienced, realistic, and have control of all external factors, you might get close. For most projects to succeed, one of these dimensions needs to be more relaxed than the others.

Fast and Good

The usual expectation is that “fast and good” won’t be cheap. Lots of people or money will be needed. But lots of people does not mean it will be done fast (see the book “The Mythical Man-Month”). So part of the solution is usually bought instead of created. That gets it done fast. But will it really be good? Maybe if you spend a lot of money, to buy something really good–essentially, you’re paying for the time that others spent on it at another company. This also assumes the part you buy will be exactly what you want.

Good and Cheap

The expectation is that a “good and cheap” solution will take a long time–that one person working on a project for a long time will be cheaper than lots of people. But will it really be good? Usually, it takes more than one person to make things good. For example reviews, proofreading, and brainstorming requires at least two people. So a few people over a long time could make a good product, but that doesn’t sound like it will be all that cheap (unless the people work for free).

Fast and Cheap

“Fast and cheap” is not likely to be good. And that is the usual way projects are started. The project gets accepted by most companies when those paying for it are convinced that it can be done fast and cheap. The assumption is that it will need to be just good enough for customers to want to buy it.

Cost, Features, Quality

But let’s break the discussion across slightly different dimensions, because “fast-cheap-good” may be a fun quip, but most product and project discussions revolve around Cost, Features, and Quality.

Continue reading Planned Obsolescence in Software