I am inferring from the article. The fundamental problem seems to be that the Engineering solution led to "land subsidence" (due to falling water table) which was then fixed for the city center but pushed to the peripheries, thus the author's telling phrase "It transforms problems, creating new and different challenges that burden other people—and future generations".
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.