
Engineers Don't Solve Problems (2018) - danielnixon
https://logicmag.io/failure/engineers-dont-solve-problems/
======
elipsey
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.

~~~
rramadass
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.

~~~
elipsey
I think you're missing my point.

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.

------
rramadass
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.

~~~
maximente
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.

~~~
godelski
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.

------
ch33zer
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.

~~~
olooney
> [...] 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.

~~~
annabellish
>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.

~~~
bsder
The engineering is fine.

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.)

------
pm90
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.

------
davidivadavid
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_.

~~~
Konnstann
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.

~~~
davidivadavid
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.

~~~
pm90
> 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.

------
sprainedankles
> 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.

~~~
ialyos
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)

~~~
rramadass
You have hit the nail right on the head!

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.

------
glitchc
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.

------
clktmr
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.

~~~
hexadec
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.

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

~~~
dredmorbius
If you're not familiar with Richard I. Cook's "How Complex Systems Fail",
you're in for a treat.

[http://web.mit.edu/2.75/resources/random/How%20Complex%20Sys...](http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf)

(And if you are, you're in for a re-treat.)

 _General Systemantics_ addresses similar points:

[https://en.wikipedia.org/wiki/Systemantics](https://en.wikipedia.org/wiki/Systemantics)

------
disabled
I would agree with this article, as an electrical engineering student.

All solutions to problems have design constraints, and all solutions are
limited. All actions have consequences.

The "move fast and break things" mentality is asking for trouble, certainly.
Even acting as prudently as possible, serious issues will arise.

------
mayormcmatt
"[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.

------
segfaultbuserr
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.

~~~
rramadass
Nicely said!

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.

------
tomohawk
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.

------
gen220
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.).

~~~
la_barba
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..

~~~
gen220
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.

~~~
la_barba
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.

~~~
Grimm1
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.

~~~
gen220
Interesting. I like this a lot.

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 :)

------
proc0
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.

~~~
rramadass
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-...](https://edition.cnn.com/2019/06/27/india/india-water-crisis-intl-
hnk/index.html) 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.

~~~
proc0
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.

------
barbarbar
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.

------
sewercake
Btr

