Cognitive Biases in Software Development
smyachenkov.com
Cognitive Biases in Software Development
1–10 of 127 posts
Re: Cognitive Biases in Software Development
#2by who can pay?
Re: Cognitive Biases in Software Development
#3Worth the click even to just skim the hilarious images that illustrate the points.
Re: Cognitive Biases in Software Development
#4Best laugh I've had all day.
Re: Cognitive Biases in Software Development
#5There's something deeply unnerving about ugly code, I don't think we can just say 'well it works'.
I think we should maybe aspire to find a frame of reference for evaluating when to change and not.
During development, I find iteration can be useful, i.e. when you have code that's 'hot in your mind' and can be re-worked.
Another key that the article doesn't seem to reference is encapsulation. It's one of the most golden concerns in software.
If 'ugly' is confined to a single function and doesn't leak outside - then it's almost pointless to re-write it.
On the other end of the spectrum, if an API is 'ugly' it leaks all around the code inside and out. Re-write is more expensive, but could possibly be more worth it.
Re: Cognitive Biases in Software Development
#6Over the past few years I have grown disillusioned by the seemingly hyper focus on clean code concept. It seems perfectly logical to have readable code. But the excess that we programmers do with the concept.
Re: Cognitive Biases in Software Development
#7The entire human race is a cognitive bias, you can't have christians and muslims be right at the same time. One population of religious people must be wrong and therefore a huge portion of the population must be cognitively biased to an extreme degree of believing in something completely wrong.
It is part of human nature to be hugely biased to a completely absurd degree and software engineers and scientists are not immune to this effect.
The worst that I've seen this in (to the best of my ability, as I'm cognitively biased too) is in design patterns.
Typical scenario:
Object instantiation requires 50 parameters to be fully realized. Some coworker suggested that we instantiate an object with empty members and create 50 methods on an object that each take one parameter to load the object.
Apparently having a function that takes 50 parameters create the object was a code smell because it didn't have a fancy name. That fancy name was "builder pattern."
If you can't see how utterly stupid builder pattern is for this case... well... cognitive bias.
Re: Cognitive Biases in Software Development
#8I think line anxiety might be another one. Unless it’s just me. If I feel that a function or a file is just irregularly long compared to the others, I find myself asking if I need to break this thing up to be more abstract
Re: Cognitive Biases in Software Development
#9I work as a "consultant", building cloud based business software. Above all else, my job is to deliver value. Something I constantly struggle with is "clean code" vs just pumping out a mostly static transaction script and moving on.
More and more, I write code I'd almost be embarrassed for colleagues to review. But for the type of work I'm doing (poorly defined, highly volatile, potentially short lifespan), I can't justify anything more.
It doesn't feel good and it's still hard to accept that I'm doing the right thing.
If the language I'm working in supported FP, then my world would be much better.
Re: Cognitive Biases in Software Development
#10Over the past few years I have grown disillusioned by the seemingly hyper focus on clean code concept. It seems perfectly logical to have readable code. But the excess that we programmers do with the concept.
Before I worked on firmware I worked on PCB layout. Thing you learn from that is you can keep fucking with the layout forever and it is simply pointless from a business perspective. Spend an extra day 'cleaning up' the layout. Well sweet now your delivery slipped a day.
Also experience with redactoring away a wart only to find there is now a wart somewhere else.