Engineers Don't Solve Problems (2018)

This article is making a lot of unattributed claims on behalf “Silicon Valley entrepreneurs”:<p>“the promise of technological fixes peddled by Silicon Valley entrepreneurs that seem to allow us to continue with business as usual.”<p>“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.”<p>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.<p>Attacking whole groups of people for unspecified and unattributed proposals is a truly obnoxious rhetorical tactic. You can blame anything on anyone this way.<p>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.

This is an excellent article. I think it is a good example of lack of whole &quot;systems thinking&quot; 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&#x2F;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 &quot;any action is better than inaction&quot; 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.

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.<p>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 &#x27;this is my solution, but it comes with caveats&#x27; will be frowned upon. Additionally, it&#x27;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&#x27;m not saying they couldn&#x27;t have, just that it&#x27;s difficult.

This seems like a misleading title. The article itself is pretty great and I would encourage folks to read it.<p>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&#x27;s another problem, and now the engineers can solve that too.<p>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&#x27;t mean all problems are defined properly. That&#x27;s why part of the hype around design thinking is about <i>solving the right problem</i> before <i>solving the problem right</i>.

&gt; 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.<p>I understand the allure of creating a system that allows the &quot;popular power&quot; to make decisions, but that in itself is a difficult problem to solve.<p>We couldn&#x27;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&#x2F;Engineers and the people such that the P&#x2F;Es say &quot;hey here&#x27;s our plan, find the flaws&quot; and the people say &quot;here are the flaws&quot;<p>But there&#x27;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&#x27;s a catch 22.<p>The decisions must eventually come down to the P&#x2F;Es, but maybe we just need to add a few more feedback points into the decision-making system.

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.

The engineers that build the new drainage system in 1975 did indeed solve the problem. The new problems are a result of bad city planning.

I learned early in my career that in engineering things are really only ever varying degrees of brokenness.

I would agree with this article, as an electrical engineering student.<p>All solutions to problems have design constraints, and all solutions are limited. All actions have consequences.<p>The &quot;move fast and break things&quot; mentality is asking for trouble, certainly. Even acting as prudently as possible, serious issues will arise.

&quot;[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.&quot;<p>This article reminded me of Kim Stanley Robinson&#x27;s novel &quot;Aurora&quot;, about a generation ship&#x27;s various engineering issues and how the inhabitants find various ways to rebalance the closed system, but never completely.

Pragmatically, I believe engineers indeed &quot;solve&quot; 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&#x27;t &quot;solve&quot; problems but &quot;transform&quot; problems.<p>It makes perfect sense to me, but is it correct to blame engineering?<p>Philosophically speaking, my pet theory is that the <i>entire history of human civilization</i> 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.<p>Although some thinkers believe we should somehow degrowth and freeze the civilization for the best interests of human happiness, I don&#x27;t think it&#x27;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&#x27;t think it would be a problem in many centuries if improvements is continued).<p>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.<p>So I don&#x27;t really think creating new problems to solve is an engineering problem and one should blame engineering for not solving problems.

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&#x27;d like to share a related theory I&#x27;ve been thinking about lately, which applies some of the ideas latent in this article to software engineering.<p>1. Code is a liability.<p>2. Therefore, adding new code to your codebase is adding liability to your codebase, at the margins.<p>3. Refining&#x2F;documenting code at the leaves transforms some of those leaves liabilities into assets.<p>4. Refining&#x2F;documenting code in the branch&#x2F;trunk transforms some of that branch&#x27;s liability into an asset, but usually undoes any progress made in the leaves.<p>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.<p>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).<p>This ties into the article, because engineers don&#x27;t &quot;just&quot; solve problems (unless you&#x27;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 &quot;solve&quot; that newly-created problem over time.<p>It sounds somewhat Sisyphean, but that&#x27;s life&#x2F;evolution! It&#x27;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&#x27;s source code, dinosaurs, etc.).

I&#x27;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&#x27;s the only example they give.

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.

Btr