it's not blaming engineers so much as recognizing that all this tech doesn't address the fundamental "problem" and may actually make it more difficult to solve or worse: he alludes to such with the lithium/electric car issue. imagine the engineers built an even better system the first time - it'd probably allow even more growth, worsening the unsolved problem.
I frequently say that we've solved (almost) all first and second degree problems (problems which are cause->effect our cause->effect->effect). A big problem that were facing today is we have high order problems and we're treating them like first degree (the call is always clear "it's easy, you just..."). We've clearly advanced to a stage, at least in the first world, were we have extremely complex issues that are interconnected with many others. Luckily we're also at a stage (in all worlds) where we can recognize this, but we need to act on it. I often see complex issues (name literally any popular topic discussed in political climate: climate, guns, civil rights, reputations, etc) addressed as simple to solve issues. While all of them are solvable, over simplifying actually distracts from the problem. And I think the author of this article would agree with me, they often make things worse in the long run. With these great advancements we've made we not only should, but have a duty, to think better about the future and complexity of the issues at hand.
A good engineer can solve a problem. A great engineer recognizes the usefulness of a thousand page reference manual on orings and uses that reference.
It is inconceivable to me that for a project of this nature and magnitude, the Geologists, Engineers etc. did not anticipate the "land subsidence" problem. They might have missed the rate of growth of the city which might have exacerbated the problem but certainly would not have repeated the same/similar mistake twice. To be sure, it is a non-trivial Engineering problem but the article seems to imply that subsequent fixes resulted in problems in other parts of the system which were not anticipated.
The author is an Environmental Engineer himself and i really found these paragraphs worthy of thought (they sound eerily true of Software Projects/Development!);
The ... System succeeded precisely by failing in the most mundane and invisible way possible. It transformed a catastrophic problem into a creeping one, out of sight ... It displaced the costs ... onto the margins, far from the centers of power—and onto future generations.
Yet ... politicians and business elites will not judge ... by its mundane failures, such as the groundwater depletion and subsidence it facilitates. These effects are slow-moving and concentrated on the urban periphery, far from the centers of power. Instead, elites will consider ... a success insofar as it prevents the kind of catastrophic flooding that might stall their dreams of a fast-growing ...
But it also has the outlines of a broader truth: in engineering, the “success” of a technology often has less to do with solving problems than rendering them opaque or distant from our imagination. Like an endless game of whack-a-mole, the problems never truly go away—they come back with a vengeance decades later and miles away in new forms, often made worse by the very infrastructure engineers created.
But to be able to wrestle with these questions, we need to change the language we use to think about engineering and technology. Saying engineers “solve problems” implies a kind of mathematical tidiness that doesn’t reflect our messy reality. This language suggests that problems just disappear or are neatly contained through technologies. ..., we should instead talk about how engineers transform problems.
This subtle shift in language brings our attention to the fact that any “solution” produces, inevitably, more and different problems—many of which may not be visible in the moment or place it is implemented, or to the particular group of people designing the intervention. This seems to be, at first glance, obvious. We often say that a given tool “creates more problems than it solves.” Yet the idiom is rarely taken to heart—even if, as engineers, we talk about tradeoffs and generate cost-benefit analyses of different “alternative solutions.” Anyone who has ever worked in an engineering firm or the government knows that these are inevitably influenced by our own biases and interests, whether conscious or not. Furthermore, not every effect of an engineering solution can be quantified in dollars and placed into our analysis.