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

Logical fallacies in software engineering

artur-martsinkovskyi.github.io

Post reply on HN
Print view View original

81–90 of 151 posts

Re: Logical fallacies in software engineering

#81

Post by scruple »

shados wrote: post #59
icxa wrote: post #48

Earlier quoted context omitted.

Mentorship at the highest level (principle to senior and below) is desperately lacking. I vow myself when I reach that level to pass it along the best I can, but something I desperately searched for when I was starting. I pair programmed for 3 months (which I consider apprenticeship / live action mentorship) with someone who was a way better engineer than me at my first "career job" out of college. I learned more in…

> I vow myself when I reach that level to pass it along the best I can, but something I desperately searched for when I was starting. Mentoring is one of my favorite thing. Finding people who want to be mentored is...challenging though. Probably a chicken and the egg (one of the other posters mention how people are put in a situation where they can't be open about not knowing things), but so many entry level engineer…

This is a salient point. I've personally found that most junior/intermediate people want to be mentored but it should always be done carefully and with consideration. I've had a couple of junior/intermediates, though, who, like you are saying, just did not want it. I think that most of them have moved on from the company but there is 1 person who is still around and who is now the type of person who has 5 years of experience but it's all the same year.

Re: Logical fallacies in software engineering

#82

Post by ctchocula »

p0nce wrote: post #62
shados wrote: post #37

Earlier quoted context omitted.

Good points. I feel software engineering as a field is growing a lot slower than it could, for a couple of reason. The first is what you mention: everyone ignores lessons from the past and try to relearn everything from scratch, reinventing the wheel and best practices over and over and over, making the same mistakes again and again. Some communities also heavily encourages concepts like how experience doesn't matter…

Part of the Stone Age is that the good stuff is already out there in books nobody reads, rather than fancy Medium posts.

Do you happen to have a list of such books off the top of your head?

Re: Logical fallacies in software engineering

#83

Post by danmaz74 »

zachrose wrote: post #47
Shish2k wrote: post #26

Earlier quoted context omitted.

Also frequently combined as "Thing X is known to be imperfect, so thing Y which we've never tried before must be better" D:

This touches on another thing, which is “Thing X is known to be imperfect, Pat says thing Y is better. Nobody else on the team has tried Y but we have all these aphorisms like ‘no silver bullet’ that lead us to think Y can’t be that good.”

When somebody presents me with a new shiny solution to a hard problem describing it as a silver bullet, I immediately become suspicious. So, it depends a lot on how good Pat says that Y is.

Re: Logical fallacies in software engineering

#84

Post by convolvatron »

Udik wrote: post #18
stupidcar wrote: post #7

The "nirvana fallacy" is definitely one I commonly see on Hacker News. The ease with which people jump from "thing x is imperfect" to "thing x is worthless" is mind-boggling. This is usually coupled with familiarity bias, where the flaws of any existing technology are discounted vs. those of a new technology.

A fallacy I've noticed often in sw engineering, and might fall under the nirvana fallacy definition, is the assumption that there is one best tool for doing things- the one that supports the largest amount of use cases. An metaphor I like to use is that of the software engineer buying a tank instead of a car: fits more people, drives on all terrain, basically indestructible, and in case an enemy is blocking the road…

I dont really take it this way. for me the 'nirvana fallacy' is that if we design a bespoke system, in the limit we will save work and end up with a better product than if we found a tank and a car, welded them together, and fixed them up.

whats not mentioned in the article is the 'never coming up for air' problem. maybe building a custom ruggedized car is worth the time investment - but the problem is that once your people get into that mode they always a new and interesting direction to take it, and never end up installing the seats and the taillights.

i still believe that an 80% implementation of some idealized system generally wins over 'just mash together some stuff to make a demo and we'll deal with the fallout later'...but since no one else does anymore its kind of moot.

Re: Logical fallacies in software engineering

#85

Post by OldHand2018 »

shados wrote: post #61
mason55 wrote: post #57

Earlier quoted context omitted.

As a counterpoint to that, in some cases technology is changing so rapidly that things which were best practices no longer are and vice versa. Things that we take for granted now, like CI/CD, were not even technically possible 20 years ago. If people weren't constantly challenging best practices as new technology came out then we'd still be pushing our CRs through change acceptance boards. Or think about "the cloud,"…

Good point, absolutely! The line is really thin between industry changing stuff (CI, cloud, distributed version control, type systems that don't suck, etc) and reinventing the wheel through arrogance or just not knowing any better (yet another testing framework, screwing up some well studied patterns :cough Java Optionals cough:)

The graybeards among us might chuckle at the thought of calling it "distributed version control" when the CI system requires a centralized copy of the repository acting as a source of truth in order to work.

Re: Logical fallacies in software engineering

#86

Post by nullc »

https://en.wikipedia.org/wiki/Argument_from_fallacy

Increasingly, I've seen being blindly dismissive due to awareness of usually helpful but sometimes harmful cognitive heuristics to be a source of mistakes in reasoning.

Human reasoning has a multitude of biases and approximations that evolution has preserved in our behavior. They are not always in our best interest, but nor is our alternative behavior when we try to act to contradict them.

Re: Logical fallacies in software engineering

#87

Post by sosborn »

mgkimsal wrote: post #29
afranchuk wrote: post #16

I'm constantly fighting the sunk cost fallacy with managers, I'm surprised it hasn't been mentioned, or maybe it has been but in a different form?

"Individuals commit the sunk cost fallacy when they continue a behavior or endeavor as a result of previously invested resources (time, money or effort)" WRT software projects, what's the opposite? When I bring up sunk cost, the assumption is that I'm lobbying for wholesale rewrite. In some (not all) cases I am - take the lessons learned, maybe some algorithms, data, whatever, and rebuild. The standard rejoinder to t…

> But sunk cost fallacy is a real thing.

The fallacy is a real thing, but that doesn't mean that it is always applicable. Decisions are based on many factors and most of the time, "We've invested a lot of money into this" isn't the only one on the table, even if it is the only one they are saying out loud.

Re: Logical fallacies in software engineering

#88

Post by nullc »

BeetleB wrote: post #65
argd678 wrote: post #51

> Some engineers may use such fallacy, exposing all the technicalities of their job to cover incompetence and justify failure in rolling out feature in time. This is certainly common, however I see more often that engineers are simply not convinced by logically sound arguments that are in fact correct and true, so you’re forced to use other methods such as authority since they’re not operating completely on reason. D…

>This is certainly common, however I see more often that engineers are simply not convinced by logically sound arguments that are in fact correct and true, so you’re forced to use other methods such as authority since they’re not operating completely on reason. Can't speak to your case, but the reality is that most SW engineering principles are opinions and not facts - even simple ones like whether we should expend e…

> Can't speak to your case, but the reality is that most SW engineering principles are opinions and not facts - even simple ones like whether we should expend effort on making code more readable.

Winner winner, chicken dinner.

Some of these things COULD one day be facts, but essentially no one has done the research to determine the fact form of the opinion.

"In code of type X maintained like Y, structure Z has been identified to cause a higher defect rate and increased lifetime maintenance costs compared to ZZ" could be a true fact, but seldom do we have any results from rigorous study.

Consistency certainly appears very useful, so appealing to some authorities opinion just to get a consistent outcome is probably a reasonable thing to do in many cases. Unfortunately, many people argue for these opinions by first confusing them for facts and defending them as such.

We'd often be better off-- in matters of code style or similar-- if teams were more ready to use and accept arguments of the form "that as far as anyone knows option X is at least as good, objectively speaking, as anything other option and for consistency sake we might as well adopt it since {our industry, our team's most prolific reviewer, our existing codebase, etc.} prefers it".

Re: Logical fallacies in software engineering

#89

Post by chadash »

__s wrote: post #72
chadash wrote: post #34

> Appeal to authority (argument from authority, argumentum ad verecundiam) – an assertion is deemed true because of the position or authority of the person asserting it. You have to be careful with this one. When someone has enough credibility, sometimes you need to question yourself if you disagree. If you are playing chess and Gary Kasparov comes along and tells you what your next move should be, you can disagree w…

This is a bit of the "fallacy fallacy" issue. Fallacies are mental shortcuts. Fallacies are wrong when you say "X is true because Y" where Y is something like an appeal to authority. But their use does not imply "X is false because Y is a fallacy". The move isn't good because Kasparov said it's good; Kasparov said it's good because it's a good move. Which means that if you asked him, "Why?" he would give you some rea…

> The move isn't good because Kasparov said it's good; Kasparov said it's good because it's a good move. Which means that if you asked him, "Why?" he would give you some reasoning, which is the real Y for why X is true.

Yes, if you have access to Kasparov, you can ask his reasoning and that will help you make a decision. Some moves in chess are only good moves if you get the next five moves exactly right, so they aren't suited to beginners.

But in real life, we don't usually get access to experts. I can look up Kasporovs games but I can't ask him his reasoning. I can look at code that Dennis Ritchie writes and see how he did something, but I don't have access to him to question him on his reasoning. But he's a very good programmer with deep knowledge and a body of work to show for it, so chances are that if he's doing something some way, it's probably not a bad way. On the other hand, if I'm writing something in C--and I'm no expert in C--I aught to give it serious thought if I'm torn between two options and I'm not choosing the one that Dennis Ritchie went with. There's a good chance that I'm not seeing something that he did.

And yes, even the best people make mistakes. But unless you have good reasoning to the contrary, you probably are not going to do better than experts in most decisions.

Re: Logical fallacies in software engineering

#90

Post by blt »

BeetleB wrote: post #65
argd678 wrote: post #51

> Some engineers may use such fallacy, exposing all the technicalities of their job to cover incompetence and justify failure in rolling out feature in time. This is certainly common, however I see more often that engineers are simply not convinced by logically sound arguments that are in fact correct and true, so you’re forced to use other methods such as authority since they’re not operating completely on reason. D…

>This is certainly common, however I see more often that engineers are simply not convinced by logically sound arguments that are in fact correct and true, so you’re forced to use other methods such as authority since they’re not operating completely on reason. Can't speak to your case, but the reality is that most SW engineering principles are opinions and not facts - even simple ones like whether we should expend e…

Good example, was that from Effective C++? Widely repeated, yet wrong.
Post reply on HN