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

71–80 of 151 posts

Re: Logical fallacies in software engineering

#71

Post by teucris »

adrianmonk wrote: post #66

Sometimes a helpful antidote to the nirvana fallacy is to choose a solution which doesn't preclude perfection. It's one thing to make a decision which blocks you off from ever solving the problem the really correct way. It's another thing to not achieve perfection now but leave open a path to going back and improving certain parts later so you eventually get there. For example, maybe one component of your code uses a…

1000% agree. My team is in the middle of building a new system, and it’s gotten to the point where I’ve found myself saying the phrase “let’s not paint ourselves in a corner” 2-3 times a day. An additional benefit is that you get to testing your solution in the real world sooner, shaping your perception of perfection (and therefore the list of needed improvements) in production rather than on paper.

Re: Logical fallacies in software engineering

#72

Post by __s »

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 reasoning, which is the real Y for why X is true. Granted he might appeal to authority by saying "Because my intuition likes it", but that's a good reason to think deeper on the move in order to come up with a grounded argument

Re: Logical fallacies in software engineering

#73

Post by mgkimsal »

akvadrako wrote: post #58
mgkimsal wrote: post #29

Earlier quoted context omitted.

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

Wholesale rewrites often have huge future costs, so I don’t think dismissing them is a sunk cost fallacy.

That's not what I was suggesting. I was suggesting that dismissing any calls for any change (whether it's whole rebuild or any degree of aggressive change) is often justified with "but we've already paid $x for this project". Couple that with then also complaining about further costs just grinds my gears.

Probably 1/3rd of the projects I've worked on over the last 20 years were software systems that were objectively/measurable poor, and probably half of those warranted a rebuild, and genuinely not 'flavor of the month' justifications. You can't cheaply and safely, for example, run a business on foxpro/db2, relying on one person in a different country with all the source code, running in a virtualized windows XP environment on Windows server 2000, while also wanting to modify your business processes and grow your business. I'm not saying it can't be done, but the costs and risks outweight whatever benefit you've already bought and paid for the last 20 years.

Re: Logical fallacies in software engineering

#74

Post by Noumenon72 »

austincheney wrote: post #9

Many logical fallacies I encounter as a developer are actively exercised so that a developer can save face or justify their existence through appeals to the ignorance of business leaders. Some I have noticed as a JavaScript developer: * Appeal to Popularity, a modification of appeal to authority. Essentially this says if a tool or approach is popular it is correct. The common assertion is that popular approaches must…

Student fallacy is also called Baby Duck fallacy, because you imprint on the first thing you see. To this day I have no idea whether Git actually sucks or I just saw Mercurial first.

Re: Logical fallacies in software engineering

#75

Post by hobs »

Silhouette wrote: post #64
mindondrugs wrote: post #50

Earlier quoted context omitted.

Oh man, I relate to this feeling tremendously. I am a junior dev on an apprentice program (just shy of 1 years experience to date) and the times I have struggled with something because I let my pride, or fear of bothering people with inane questions, have been the lowest points in the last year. I always get to the otherside wishing I just talked to a senior dev - because more likely they could have saved me a stress…

For whatever it might be worth, here is my advice to juniors about being mentored: It mostly is true that the only stupid question is the one you didn’t ask. Please don’t ask the exact same question twice. Take notes if you need to. Asking for clarification or following up for more detail is fine. If you have many questions and your mentor has other responsibilities, try not to keep interrupting them all the time. Di…

Also - make sure they understand your goals instead of your hyperspecific question - a lot of time can be saved by avoiding the XY problem.

http://xyproblem.info/

Re: Logical fallacies in software engineering

#76

Post by justapassenger »

mindondrugs wrote: post #50
wpasc wrote: post #45

Earlier quoted context omitted.

May I add to this with a third: difficulty in creating a strong system of mentoring? Many companies have a formal mentorship program but it is often in name only (at least in my experience at 3 companies). In a formalized apprentice program, a worker can feel okay about not knowing things and asking the person for whom they are apprenticing. Despite formal mentors, I believe many junior devs do not have a person that…

Oh man, I relate to this feeling tremendously. I am a junior dev on an apprentice program (just shy of 1 years experience to date) and the times I have struggled with something because I let my pride, or fear of bothering people with inane questions, have been the lowest points in the last year. I always get to the otherside wishing I just talked to a senior dev - because more likely they could have saved me a stress…

Few random thoughts as someone who mentored many junior engineers:

- don’t care about your pride. You’re here to learn, so do everything you can to learn. Imagine even the worst possible scenario - people get fed up with you - you’ll go and find different job (benefits of being in a booming industry). Your old coworkers won’t follow you but knowledge will

- don’t think about all the time you spent looking for answers yourself as wasted. Some if it was, but you learnt also tons of other things that may not be relevant now, but will be in a future

- ask your mentors not only for direct answers to your questions but also for reason and/or how they came to that conclusion. Most important skill for you to learn is how to think about problems and how to find solutions, not the actual solutions to few problems you came across

Re: Logical fallacies in software engineering

#77

Post by mgkimsal »

lazyasciiart wrote: post #68
mgkimsal wrote: post #29

Earlier quoted context omitted.

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

You clearly lay out the future costs of both options in a way that demonstrates you aren't just unaware of how much work will go into the change. That said, rewriting a system you don't understand is pretty hard to do successfully.

the problems aren't usually technical as much as political or 'business' generally (though sometimes technical stuff presents challenges, certainly).

There's almost always an assumption, I've found, when coming in to existing projects, that they "really" work a certain way and maybe there's just "a bug here" or "some small fix needed over there". Sometimes that's the case, but more often than not, even after those things are 'fixed', nothing actually does what the people in charge thought it was doing. They've sometimes fundamentally misunderstood what they'd required/specced out with a previous team, or, in some cases, the previous team really didn't know how much they didn't know, or in a couple case, they were simply lying for months on end, cashed checks, then left.

"rewriting a system you don't understand is pretty hard" getting a team to successfully spec out what they need is pretty hard, imo, regardless of whether it's greenfield, rebuild, or clarifying expected behaviour in a current system. The big challenge I've come across with "incremental changes to existing systems" happens when it really doesn't do (and never did) what people thought was happening.

"No, this isn't calculating daily compound interest - it's calculating monthly."

"No, the reports aren't able to be regenerated from previous points in time because historical information was never stored anywhere - you simply now don't have 4 years of data you thought you had - the previous reports you were told were being regenerated were just being pulled from a cache."

Fixing problems like above may mean battling through lots of bad code and many many contentious discovery/planning/testing meetings, and... the result is now someone has a 'functioning' system running on codeigniter 2 with hard dependencies on php 5.2.

Years ago I faced a situation with a Rails app which "just needed a few modules finished and a few tweaks". It was done in Rails 1 and had insane amounts of runtime monkey patching. 3 different Rails shops I went to indicated it was not worth the time/effort to try to 'upgrade' what was there. They'd rebuild greenfield and salvage what bits they could from the previous project.

Many of my experiences have been with smaller organizations (less than 50 people - sometimes less than 10), and there's rarely a full team of competent IT people who can review/vet/verify. "Never rebuild from scratch" - it's not bad advice, but it has a lot of assumptions that aren't always true.

Re: Logical fallacies in software engineering

#78

Post by [deleted] »

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…

[deleted]

Re: Logical fallacies in software engineering

#79

Post by scruple »

icxa wrote: post #48
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…

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'm writing the book on senior+/lead to junior/intermediate mentoring with my company. I've been floating my notes and mentoring guidelines around the department heads and other leads. I love it, personally. Department heads and managers see the value but are reluctant when they see that I'm willing to spend months with a junior or that I might myself out there for hours a week with an intermediate. If I come across a particular interesting performance problem, or something like that that is challenging and requires a certain type of experience to get into, I'll schedule time to pair with 1-3 of my team members on it so that they can hopefully benefit from the experience. The real challenge, though, is that not everyone wants to mentor. I personally think that it's critical and a core part of my responsibility but most of the other senior+/leads where I work are not engaging in much meaningful mentorship with their teams.

Re: Logical fallacies in software engineering

#80

Post by bobbiechen »

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 have any book recommendations?
Post reply on HN