This article is making a lot of unattributed claims on behalf “Silicon Valley entrepreneurs”:
“the promise of technological fixes peddled by Silicon Valley entrepreneurs that seem to allow us to continue with business as usual.”
“But if we are to listen to Silicon Valley entrepreneurs and their allies in government and academia, we should not worry about changing our collective way of living on the planet: climate change is simply a problem that can be solved with “disruptive” new engineering innovations, from carbon capture and storage to electric cars.”
The only direct quote is from an unnamed Tesla executive answering an unspecified question: “those are questions for philosophers—next question.” For all we know, he might have been asked why bad things happen to good people.
Attacking whole groups of people for unspecified and unattributed proposals is a truly obnoxious rhetorical tactic. You can blame anything on anyone this way.
Edit: I want to clarify that I think the thesis of the article, that engineering is used both to enact and obscure political outcomes, is true and important. The engineering problems described are a fine example of this dynamic, and I wish the author had stopped there, rather undermining this important argument in such an easily avoidable way.
I think you are being a little uncharitable towards the author here. He was just pointing to the "Silicon Valley" crowd as an example of the highly visible/vocal proponents of "Technology will solve Everything" dogma without necessary foresight. The caveat is that Technology may solve your immediate problem but also create far more severe ones in the process. And he is right. The whole of Human Civilization is rife with such examples. At this stage in our "progress" we are sufficiently knowledgeable enough that we should always focus on long-term whole systems-view of everything.
If we wish to be taken seriously when attributing claims or beliefs to people, we need to substantiate those with evidence like a cited quote, not just hearsay. The author is PHD candidate so they should understand why it is important to cite sources.
This is an excellent article. I think it is a good example of lack of whole "systems thinking" and a failure to really understand the scale of the problem. The main issue it seems to me is that the problem was evaluated and solved only in one given context without thinking through long-term future ramifications. I am almost willing to bet that this was due to the Suits/Politicians wanting to get something done rather than allowing time for the Engineers to fully evaluate the problem and come up with a robust solution. The oft repeated trope "any action is better than inaction" is not applicable under all circumstances. The complexity, scale and risk analysis of the problem should dictate whether one needs to spend more or less time evaluating it. It seems in this case nobody got those parameters right.
the takeaway from the article to me was, despite whatever tech implementation they chose - be it better drainage, rainwater capture, recycling, etc. - it wouldn't solve the issue that Mexico City is just growing way too fast for its own good.
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.
This is how I read the article as well. Which makes the title a misnomer in one sense but correct in another, which I think was the intent. Technology is great and no doubt makes our lives better, but it isn't a cure all.
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.
I read it as, The growth of Mexico City may have accelerated and exacerbated the problem but certainly "unintended consequences" from the projects were not planned for. It is not a blame game as much as asking how could Engineering not have thought of such future catastrophes and planned accordingly. He provides the answer himself; it is because the failures were slow and creeping and hence the Politicians/Bean counters ignored them in pursuit of short term "development".
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.
I 100% agree with this article, but I suspect it will not be well received here. HN is so focused on innovation at all costs that anything that goes against that will be rejected.
I think that one of the issues with doing as the author suggests and thinking of technology as a transformation is that it can be hard to come up with the downsides of your new tech. Engineers will constantly be encouraged by management and customers to deliver a solution, and often saying 'this is my solution, but it comes with caveats' will be frowned upon. Additionally, it's clear in retrospect that the expansion of the city the grand canal allowed would lead to depletion of the ground water which would lead to sinking of the city and the canal being inneffective, but was that known at the time? Could engineers working on a canal project have anticipated socioeconomic trends like this? I'm not saying they couldn't have, just that it's difficult.
> [...] was that known at the time? Could engineers working on a canal project have anticipated socioeconomic trends like this?
Mexico City has grown from 4 million in 1951 (the time of flood mentioned in the first paragraph) to over 20 million today. Few civil engineering projects solve problems 70 years in the future for a city five times as large. As far as I can tell from the article, the engineers did anticipate population growth and designed a system that would last for decades; furthermore, they monitored the system, were aware of stresses and possible failure points, and took several appropriate corrective actions as the decades went on. All of this is just from reading the article.
If at my job I criticized a design by saying, "this design is terrible because if it is wildly successful and gives us 5X growth, then 70 years from now it might require some rework" I would be laughed at. If I followed it up by suggesting that this reflected some sort of fundamental problem with the methods of engineering I would probably not be taken seriously. Engineers are not godlike miracle workers, setting in motion an ineffable plan that somehow make the world holistically better over an indefinite time frame. It's OK to just solve the tractable problems in front of us and to get a good couple of decades out of a system.
>It's OK to just solve the tractable problems in front of us and to get a good couple of decades out of a system.
Is it? Is it really? The point the article is making is that by designing a system which solves the problems in front of them to get a good many decades out of a system, those engineers have actually made other problems worse. I think you're being overly simplistic when you suggest that the problem the article is proposing is that the system requires some rework.
The problem the article is proposing is that fundamental, irreperable damage has been done. We can't un-do that damage. Short term thinking like what you're proposing is, by the vast majority of evidence and evidenced theories, destroying our world and risking the survival of our species. It is not okay to just solve the problems in front of us now if the cost is that all our children die in chaos and poverty--and it looks like the cost is just that.
You simply need to remove 15 million people to somewhere else.
So what is your solution to that?
(The lesson from Katrina is simply that there IS no solution--you have to let things build until a catastrophic event finally forces people out of the area.)
I just don't see the same takeaway here. Engineers don't go around building sewer systems for kicks. They were commissioned by people who were far more interested in the short term gain than for any long term considerations.
We see the same problem with the U.S.'s approach to the levee system. A neighborhood commissions an engineer to spare their homes from flooding, but without any care taken to protecting those homes outside of town lines.
The problem here isn't with the engineer; the problem is North America's unwillingness to fund long-term solutions that benefit everyone, not just a chosen (and temporary) few.
This seems like a misleading title. The article itself is pretty great and I would encourage folks to read it.
The engineers did solve one problem, that of the flooding in the metropolitan city center and they did it pretty well. The transformation the author mentions is the side effect caused by hauling all that water away instead of letting it sink into the ground and replenish the water table. That's another problem, and now the engineers can solve that too.
Damming rivers across the US kickstarted the US economy after the Great Depression but also lead to unintended consequences (depleted water supply downstream, silt buildup near dams etc.). It is the nature of engineering to solve one problem at a time; only an Oracle could forsee all possible consequences of engineering works.
Engineers solve problems. Doesn't mean all problems are defined properly. That's why part of the hype around design thinking is about solving the right problem before solving the problem right.
Working with limited information means making decisions that might turn out to be bad ones down the line. I agree with your statement, but the opportunity cost of figuring out the exact right problem to solve is inaction, and inaction is often worse than making a poorly-informed judgement.
> but the opportunity cost of figuring out the exact right problem to solve is inaction, and inaction is often worse than making a poorly-informed judgement.
That reminds me a lot of the days when managers did not want to do proper code testing and coverage because without that they could ship more code. Defining the problem upfront and doing rapid iteration not just on the solution but also problem definition is nowadays more important and effective than just shipping.
Definitely a legitimate consideration. There's always a balance between exploring and exploiting, with an equilibrium point somewhere. My experience is biased by many situations where exploration was unduly limited.
Or was just not done in good faith. Which is why having a culture of openness and honesty and acceptance of failure (to an extent) is important to building an effective engineering culture.
Agreed, and in the author's instance that makes sense but generalizing the problems faced in a specific region that is known for not-so-great government to engineering as a whole is ignoring a lot of context to decision-making, good or bad.
Engineers solve problems but we have to work within constraints - be it technological, economic, political etc. It's very rare (never in my career) that I've been given free reign to implement a "perfect" solution.
There is always, always trade offs involved in engineering. As for which trade offs are acceptable sometimes you have influence over that and sometimes it's out of your hands. Design thinking is a tool that can help but it is not a panacea.
For people that don't work in the field perhaps it's not obvious. A good friend of mine is a PHD chemist who works in research (I work as a Materials Engineer in industry) he is always winding me up about engineers doing a half-assed job. I've always thought that our interactions highlight one the key differences between science and engineering, scientists strive for perfection if you will and engineers want workable...
And a bit of a big ask connecting some SV scooter sharing start up to old school civil engineering.
From experience working for a leading hydrodynamics organisation you don't mess around with nature lightly ok you can do costal defence but you just move the problem around.
Oh and normally its the technician who fixes the "engineers" math :-)
> The challenge we face as a society is to build the structures of popular power to decide collectively which burdens are worth their weight, and how to distribute them justly. These are not choices we should leave to politicians, or even engineers.
I understand the allure of creating a system that allows the "popular power" to make decisions, but that in itself is a difficult problem to solve.
We couldn't possibly crowd-source how to solve this flooding problem until the majority of that crowd has been educated on several aspects of the issue. Perhaps what the author is implying is that there needs to be a better interface between Politicians/Engineers and the people such that the P/Es say "hey here's our plan, find the flaws" and the people say "here are the flaws"
But there's the difficult problem. There will always be flaws and trade-offs, and this kind of interface eats up large amounts of time that may be better spent implementing a short-term solution to buy a few more years until a long-term solution is reached. It's a catch 22.
The decisions must eventually come down to the P/Es, but maybe we just need to add a few more feedback points into the decision-making system.
I took this quote to mean the following:
Engineers are well equipped and positioned to understand the set of solutions that are available to them and the material negative impacts of those solutions (e.g if we build a dam at spot x, the region y might have an increase in floods). But engineers should not be given the ability to make decisions about which of set of negative impacts a society should bear, and that should instead be a decision made collectively.
So the interface between the engineers and the people is not to find solutions together, or to find flaws together, but for engineers to find solutions and flaws, and the people to pick the one that they are happiest with.
(I'm not certain my understanding of the quote is right, just sharing my interpretation / an alternative to the ones you shared)
The costs(in various dimensions) of an Engineering decision in projects of this magnitude is borne by the whole population itself. Therefore the populace must have a seat at the decision-making table to choose amongst alternatives.
this seems to ignore a crucial section of the article, which details how the engineers decide to in this case close particular sections of the drainage system to ostensibly protect the powerful, even when it affects neighborhoods their families live in.
if as you say,
> The decisions must eventually come down to the P/Es
then there's reason to believe that an entire class of people will always bear the externalities of these "solutions", which are solutions in the sense of out of sight, out of mind.
Sounds like a city planning problem rather than an engineering problem. Engineers design solutions to specifications, budgets and constraints. The latter two often dominate the shape and form of the final solution. That the poor areas flood first doesn’t sound like an accident. I am reasonably confident that the original designers presented all of the caveats in their solution, and the elites were happy with the trade-offs and signed off accordingly.
That is the point of the article though. But they did not really solve the issue, it just highlighted a new issue. Engineers solved the flooding of the city but brought to light the fact that groundwater pumping is causing the city to sink. So they solved the short term issue but the root problem is still getting worse.
"[I]n 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."
This article reminded me of Kim Stanley Robinson's novel "Aurora", about a generation ship's various engineering issues and how the inhabitants find various ways to rebalance the closed system, but never completely.
Pragmatically, I believe engineers indeed "solve" problems. However, the author is getting philosophical here, and argues the solutions themselves would create its unique, unforeseeable problem in the future. Thus engineers don't "solve" problems but "transform" problems.
It makes perfect sense to me, but is it correct to blame engineering?
Philosophically speaking, my pet theory is that the entire history of human civilization is an eternal process of solving existing problem by creating new forms of societies, thus creating their own problems, ad infinitum. It began since the use of fire, the invention of language and systematic agriculture, and moving towards more complex forms, simply because it has to be. I think some radical philosophers have not only argued that the industrial revolution was a mistake, but that the civilization itself can be seen as a type of technology, and it was a mistake.
Although some thinkers believe we should somehow degrowth and freeze the civilization for the best interests of human happiness, I don't think it's really coming. The human civilization on Earth is a very centralized system today. It may be possible in a future space age where human civilization spreads across the galaxy when centralization would be no longer possible and enable some regions to choose a primitive approach to civilization, or in a future digital age when computational resource is practically post-scarcity that enables minds and civilizations to exist independently in cyberspaces (even then, engineers have to work tirelessly to increase the computational power of the system before it collapses, although the laws of physics have set an extremely high upper limit for reversible computation, unlike many types of physical resources, so I don't think it would be a problem in many centuries if improvements is continued).
But before that, the ride will go on. If we are lucky enough not to accidentally destroy ourselves from a massive environmental incident or a world war, and we can keep engineering new solutions before the current system collapses, the ride towards, at least solar system domination, seems certain.
So I don't really think creating new problems to solve is an engineering problem and one should blame engineering for not solving problems.
I don't think the author is blaming Engineering/Engineers so much as cautioning them against short-term thinking when the consequences of getting it wrong can be so catastrophic.
City gets built on a lake bed. Engineers are called in to fix the obvious problems that result. Engineers are then blamed for not solving the problems.
I'd like to share a related theory I've been thinking about lately, which applies some of the ideas latent in this article to software engineering.
1. Code is a liability.
2. Therefore, adding new code to your codebase is adding liability to your codebase, at the margins.
3. Refining/documenting code at the leaves transforms some of those leaves liabilities into assets.
4. Refining/documenting code in the branch/trunk transforms some of that branch's liability into an asset, but usually undoes any progress made in the leaves.
5. We are paid to (a) create liabilities and (b) transform liabilities into assets. If you do too much of (a) and not enough of (b), you are a bad engineer.
The fun thing is that you can analyze a software program like this (module A is a leaf to module B). You can also analyze the whole stack like this (Redux is a leaf to React, is a leaf to JS, is a leaf to Chromium, is a leaf to Intel, is a leaf to the Van Neumann model).
This ties into the article, because engineers don't "just" solve problems (unless you're Van Neumann?). Usually, we first create a problem (which is usually the dual of problem we are nominally paid to solve), and then we very slowly and iteratively "solve" that newly-created problem over time.
It sounds somewhat Sisyphean, but that's life/evolution! It's a joy to see things slowly crystallize into highly-functional, specialized components. Even if those components will inevitably become obsolete one day, they will still make for interesting fossils (see Zork's source code, dinosaurs, etc.).
Hmm, but how do you establish whether a piece of code is a liability? Do you account for QA finding no issues, or do you weigh it against the number of years its been used in production, or do you consider that it was written by expert rather than a novice, do you take into account the fact that it was purposefully designed, as opposed to organically etc. I think your theory is nice, but a bit too reductionist to be applicable in the real world..
I agree that my theory is reductionist, but on the flip side, that also keeps it simple and interesting to talk about, like we are now :)
I start with the very debatable axiom that all new code begins its life as liability. I've argued this in the past by deduction:
You type a single character into your editor, and (depending on the change, and your language's execution story), you've probably broken your code. Type a few more characters, and it is now less of a liability, because it compiles. A few words more, and it is less of a liability, because it accomplishes some small task (imperfectly). By the time you have committed some set of changes into version control, you've hopefully ironed out the liabilities. But, it's entirely possible that you've created more liabilities than assets. Code review hopefully refines it further, but things still sneak through. I could keep going, but I think this is clear?
Measuring the liability:asset ratio for a given piece of code is a challenge, and is more qualitative than quantitative. I believe that this is also an argument in favor of "new code is a liability", otherwise code review should catch all of our mistakes.
But yeah, I have found it to be useful "in the real world" as a heuristic for thinking about how code bases evolve over time. I do not think that it translates into a hard-and-fast rule to weaponize in code reviews. However, it does temper your expectations about the fallibility of code, and it is also a convincing argument for code review as a quality-control process.
Sure, but there are several arguments for doing code reviews/QA/etc that are already convincing. Its interesting.. but I guess I don't see how we can use this new way of looking at code transformations to our benefit.
The thing is even if QA and testing is fine now as the business or domain needs evolve over the years just the fact the context has changed can lead that code to be a liability. I'm kind of tired from work so I hope I can make my point: As an example, let's say you have a billing system that allows anonymous payment that works fine it has thus far been an asset, but new legislation is released that states that all purchases must have legal identity associated. Orwellian thought aside, some or all of that code has transformed into a liability depending on how deeply ingrained anonymous payment is and whether or no you can extend the existing code or you have to rip it out. Your code can be perfectly functional but a change to the domain need rendered it a liability.
All Code implements a process. If the requirements for that process change (due to shifting regulation, for example), the process is a liability until it adapts to those requirements, at which point it can again become an asset.
If a process has no artifacts for implementing it, it can’t be a liability.
That’s why we see so many companies offering regulatory compliance as a service, in the healthcare space for example (AHIP, NIPR). Because if every insurer had to write code that integrated with regulation, they would be writing a lot liability. Using a vendor allows them to offset that liability to a third party, whose whole purpose in existence is to maintain a nice liability:asset ratio.
Perhaps we’ve found a utility for my theory, in contributing to the build vs buy discussion :)
I've been to Mexico DF once. I visited downtown and there was a literal mountain of garbage in the central plaza (easily two stories high). Maybe Mexico City engineers are shit (pun intended), at least article implies it as it's the only example they give.
You are being flippant. The Mexico City problem is the author's research study (do a little bit of googling on the author) and therefore it is the example he knows best. The article also does not denigrate Mexican Engineers; you are reading it through your own unwarranted biases.
And finally, just so you know this is a problem with all major urban centers throughout the world. Here is a scary report on India - https://edition.cnn.com/2019/06/27/india/india-water-crisis-... This is a thorny problem for Govts, Politicians, Urban planners and Engineers which if not properly evaluated will have catastrophic consequences. That is why when people do research on this and point out problems and possible solutions, you listen carefully with gravitas.
To be clear, I was only talking about this particular problem, and engineers who might deal with it, not engineers in general. That was my experience when I visited, and apparently at the time the problem was not being dealt with properly. India is probably not a good example of how this happens in a lot of cities either, but I'll grant that Mexico DF has location problems from being on top of a lake etc.
It seems like author is studying water crisis in Mexico City. Based on problems here - author states that no problems are solved - just transformed. Though one should think that bridges, tunnels, trains etc. was solving problems.
“the promise of technological fixes peddled by Silicon Valley entrepreneurs that seem to allow us to continue with business as usual.”
“But if we are to listen to Silicon Valley entrepreneurs and their allies in government and academia, we should not worry about changing our collective way of living on the planet: climate change is simply a problem that can be solved with “disruptive” new engineering innovations, from carbon capture and storage to electric cars.”
The only direct quote is from an unnamed Tesla executive answering an unspecified question: “those are questions for philosophers—next question.” For all we know, he might have been asked why bad things happen to good people.
Attacking whole groups of people for unspecified and unattributed proposals is a truly obnoxious rhetorical tactic. You can blame anything on anyone this way.
Edit: I want to clarify that I think the thesis of the article, that engineering is used both to enact and obscure political outcomes, is true and important. The engineering problems described are a fine example of this dynamic, and I wish the author had stopped there, rather undermining this important argument in such an easily avoidable way.