Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineers Don't Solve Problems (2018)

logicmag.io

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Engineers Don't Solve Problems (2018)

#41

Post by la_barba »

gen220 wrote: post #36

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/trun…

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

Re: Engineers Don't Solve Problems (2018)

#42

Post by gen220 »

la_barba wrote: post #41
gen220 wrote: post #36

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/trun…

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…

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.

Re: Engineers Don't Solve Problems (2018)

#43

Post by bigger_cheese »

davidivadavid wrote: post #2

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 .

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

Re: Engineers Don't Solve Problems (2018)

#44

Post by rramadass »

elipsey wrote: post #32

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 ch…

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.

Re: Engineers Don't Solve Problems (2018)

#45

Post by rramadass »

segfaultbuserr wrote: post #39

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 c…

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.

Re: Engineers Don't Solve Problems (2018)

#46

Post by rramadass »

ialyos wrote: post #18
sprainedankles wrote: post #15

> 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 c…

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 shou…

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.

Re: Engineers Don't Solve Problems (2018)

#47

Post by rramadass »

proc0 wrote: post #34

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.

Re: Engineers Don't Solve Problems (2018)

#48

Post by la_barba »

gen220 wrote: post #42
la_barba wrote: post #41

Earlier quoted context omitted.

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…

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…

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.

Re: Engineers Don't Solve Problems (2018)

#49

Post by elipsey »

rramadass wrote: post #44
elipsey wrote: post #32

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 ch…

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 w…

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.

Re: Engineers Don't Solve Problems (2018)

#50

Post by Grimm1 »

la_barba wrote: post #48
gen220 wrote: post #42

Earlier quoted context omitted.

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…

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.
Post reply on HN