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

141–150 of 151 posts

Re: Logical fallacies in software engineering

#141

Post by humanrebar »

jacquesm wrote: post #134
humanrebar wrote: post #24

Earlier quoted context omitted.

Agile is a set of values, not a methodology. You're thinking of scrum or extreme programming or kanban or something more specific.

I really hope this was an attempt at deadpan humor given the grandparent of this comment.

Nope. The Agile Manifesto is a list of values. There's no method to misapply.

The real irony is people claiming to "value individuals and interactions over processes and tools" turning around and telling engineers that the problem is their processes and tools.

Re: Logical fallacies in software engineering

#143

Post by BubRoss »

coldtea wrote: post #133
whack wrote: post #120

Earlier quoted context omitted.

We're arguing over semantics here. Most people interpret a "fallacy" as something one should refrain from. Ie, "appeal-to-authority is a fallacy, therefore we should refrain from it during the course of any discussion". I'm making the point that often times, appealing to authority is most likely to produce the correct answer.

> I'm making the point that often times, appealing to authority is most likely to produce the correct answer. That's true for most so-called fallacies. Instead they are evolutionary shortcuts to getting the correct answer (at least at evolutionary kind of situations).

This is not true. There is a difference between logical fallacies and judgement based on probability. Circular reasoning, strawman arguments and actual appeals to authority are not the same as taking into account the likelyhood than an expert is correct.

Re: Logical fallacies in software engineering

#144

Post by sytelus »

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 bad proposition and I'm afraid a wrong one. When you disagree with an expert, the expert should be able to convince you why s/he is right or at least able to articulate the reasoning. It's not a chess game where you are an opponent to the expert and the next move is supposed to be secret. The relation between you and the expert is of collaboration, training and dissemination of knowledge. If an expert fails to articulate the reasoning, I take that as a sign that advice is merely because "it would work because I saw it worked before". That often means the expert failed to analyze and learn from his/her success and is just proposing the status quo. It is often better to question this kind of expert advice and that's how progress has almost always been made throughout human history.

Re: Logical fallacies in software engineering

#145

Post by rswail »

shados wrote: post #37
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…

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 problem is the concept that programming is "engineering". It explicitly is not, it doesn't have a defined set of criteria for evaluating design or ensuring results.

"Doing Agile" doesn't qualify as "engineering", CMMI level So we're still in the "master/apprentice" and "journeyman guild" days of our profession. But Universities and Colleges are desperate to sell their 4 year "software engineering" degrees, so cover up the lack of rigor with a mountain of bullshit.

So the first step to really establish software development as an engineering discipline is to stop fooling ourselves. Being able to "refactor my FactoryManagerFactory class" is not engineering.

When a programmer has to sign off and take liability for any failures like a PE does on a bridge is when we'll be able to say we are "engineers" with a straight face.

Re: Logical fallacies in software engineering

#146

Post by drainyard »

rswail wrote: post #145
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 problem is the concept that programming is "engineering". It explicitly is not, it doesn't have a defined set of criteria for evaluating design or ensuring results. "Doing Agile" doesn't qualify as "engineering", CMMI level So we're still in the "master/apprentice" and "journeyman guild" days of our profession. But Universities and Colleges are desperate to sell their 4 year "software engineering" degrees…

I would argue that we have people who already are software engineers. People who know the machine their code is running on very well, and use this knowledge to fully optimize for that specific machine (embedded, console development).

They take what they are given, and engineer a solution that fits that piece of hardware as well as possible. No bullshit FactoryManagerFactory.

Re: Logical fallacies in software engineering

#147

Post by drainyard »

jkoudys wrote: post #56
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…

I come across this one all the time, but it's usually in the form of "I know you're wrong, because person X made an argument that I don't understand, but this misunderstood summary of that argument says you're wrong". Happens all the time with the old Donald Knuth chestnut about "premature optimization". Half the time I hear it, it's from people who don't want to optimize at all. http://www.joshbarczak.com/blog/?p=58…

That Knuth quote has to be one of the quotes that is most often taken out of context to suit a current narrative.

Re: Logical fallacies in software engineering

#148

Post by tirumaraiselvan »

MaxBarraclough wrote: post #39
tirumaraiselvan wrote: post #14

Earlier quoted context omitted.

Appeal to authority - mentioned in the article.

It's not strictly identical, as it introduces ageism.

True. But age is used as a good proxy for determining authority.

Re: Logical fallacies in software engineering

#149

Post by __s »

chadash wrote: post #89
__s wrote: post #72

Earlier quoted context omitted.

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

> Some moves in chess are only good moves if you get the next five moves exactly right, so they aren't suited to beginners.

This is important. Similar issue exists in StarCraft: good builds for pro players aren't necessarily good builds for regular players. If you can't macro behind double pronged harass, don't do it. If you can't watch your ramp to block adepts shading in, don't sit a probe at the top of your ramp

Don't say "I do this because experts do this", instead study it to understand why they do. Otherwise you're going to end up cargo culting

Better to do suboptimal well & with understanding than try do optimal poorly & be confused when it doesn't pay off

Re: Logical fallacies in software engineering

#150

Post by p0nce »

bobbiechen wrote: post #80
p0nce wrote: post #62

Earlier quoted context omitted.

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 have any book recommendations?

Yes.

This is only one of these "must-read book list", what you can do is search several of them and see which ones are quoted by almost everyone!

About "everything" I would rate the following books very highly, for their sheer usefulness:

- Thinking Fast and Slow (really do the exercises!)

- then Neuroleadership which describes the purpose of brain structures, it's somehow wider than kahneman

- A Mind for Numbers (include very useful data points for knowledge workers)

- Distinction: A Social Critique of the Judgement of Taste

- Cutting Through Spiritual Materialism

About programming I would rate the following books highly, but at the same time it seems a bit fruitless to me to read about programming, rather than spending more time reading about psychology or sociology:

- the Economics of Software Quality

- Peopleware

- Pragmatic programmer

- Mythical Man month

^you'll see that these books are hardly kept secret, it's just that people quote them but don't actually read them, or so it seems.

Post reply on HN