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

Bad scientific code beats code following "best practices" (2014)

yosefk.com

Post reply on HN
Print view View original

11–20 of 333 posts

Re: Bad scientific code beats code following "best practices" (2014)

#11

Post by bottled_poe »

fulafel wrote: post #7

> Simple-minded, care-free near-incompetence can be better than industrial-strength good intentions paving a superhighway to hell. The "real world" outside the computer is full of such examples. Overengineering is insidious - "It is difficult to get a man to understand something, when his salary depends upon his not understanding it". A team can sell a solution better than a single person fixing something without mak…

any code base that evolves over time will have complexity. It can be either manageable or unmanageable complexity. Either sacrifice maintainability for early development velocity, or plan for medium-to-long term velocity. You CAN have both velocity and maintainability, but the engineers will be expensive. Fast, good, cheap - pick two. A tale as old as bits.

Re: Bad scientific code beats code following "best practices" (2014)

#12

Post by jurschreuder »

This is so true I don't think I ever read something so true.

It's not even scientists vs software developers. It's people who are really into software development and clean code.

They say the program needs a total rewrite and proceed to add 20 layers of inheritance and spreading out every function over 8 files.

Ever since I make sure to repeat my mantra every week to developers:

How maintainable code is is measured in how many files you have to edit to add one feature.

Re: Bad scientific code beats code following "best practices" (2014)

#13

Post by briantakita »

Some people incorporate antipatterns into their practice & reinforce these antipatterns with years of experience. All fields have this issue. Bad professional scientists are often worse than effective amateur scientists. Having good first principles with little experience often beats plenty of experience with bad first principles.

I have learned to appreciate codebases which break some rules & yet are easier to maintain for some reason(s) Distilling the reason(s) identifies areas where I can modify my technique...or at least help identify questions & alternatives to some techniques that I regularly use.

Re: Bad scientific code beats code following "best practices" (2014)

#14

Post by InSteady »

jayd16 wrote: post #8

If the non programmers commit correctness bugs and the programmers are just using patterns you don't like, maybe try to understand the patterns instead of balk at them.

The author states they are primarily a software engineer and have also been guilty of following these patterns, so the clear implication is that they understand the patterns. The author isn't making the case "I don't like it," they are making the case that these patterns actually lead to more and bigger problems in the field of scientific computing than the usually simple errors of ignorance committed by non-programmers.

Re: Bad scientific code beats code following "best practices" (2014)

#16

Post by nvy »

namaria wrote: post #6
palata wrote: post #2

TL;DR: a counter-productive rant against software engineers, claiming that bad code from software engineers is worse than bad code from scientists. Did you consider hiring an experienced software engineer as a lead?

You know, 96% of businesses (and by extension codebases) have to get by software wise without high priced software engineers. They couldn't afford it. The vast majority of running code is produced by people whose understanding of computer systems and programming goes as deep as how much documentation they need to ctrl+f through to get some specific tasks done.

>The vast majority of running code is produced by people whose understanding of computer systems and programming goes as deep as how much documentation they need to ctrl+f through to get some specific tasks done.

I doubt this very much. Surely the vast majority of running code is some chunk of Chrome, Android, or the JVM ("billions of devices run Java...") or something. All those things were produced by software engineers with more than surface-level understanding.

Re: Bad scientific code beats code following "best practices" (2014)

#17

Post by fulafel »

bottled_poe wrote: post #11
fulafel wrote: post #7

> Simple-minded, care-free near-incompetence can be better than industrial-strength good intentions paving a superhighway to hell. The "real world" outside the computer is full of such examples. Overengineering is insidious - "It is difficult to get a man to understand something, when his salary depends upon his not understanding it". A team can sell a solution better than a single person fixing something without mak…

any code base that evolves over time will have complexity. It can be either manageable or unmanageable complexity. Either sacrifice maintainability for early development velocity, or plan for medium-to-long term velocity. You CAN have both velocity and maintainability, but the engineers will be expensive. Fast, good, cheap - pick two. A tale as old as bits.

I think it's not a zero-sum game, you can win by judiciously avoiding incidental complexity.

Re: Bad scientific code beats code following "best practices" (2014)

#18

Post by erhaetherth »

jurschreuder wrote: post #12

This is so true I don't think I ever read something so true. It's not even scientists vs software developers. It's people who are really into software development and clean code. They say the program needs a total rewrite and proceed to add 20 layers of inheritance and spreading out every function over 8 files. Ever since I make sure to repeat my mantra every week to developers: How maintainable code is is measured i…

That's a slippery mantra. I can see putting everything in one file.

Re: Bad scientific code beats code following "best practices" (2014)

#19

Post by aragilar »

zmgsabst wrote: post #10
fulafel wrote: post #7

> Simple-minded, care-free near-incompetence can be better than industrial-strength good intentions paving a superhighway to hell. The "real world" outside the computer is full of such examples. Overengineering is insidious - "It is difficult to get a man to understand something, when his salary depends upon his not understanding it". A team can sell a solution better than a single person fixing something without mak…

Prime Finance (at Amazon) did that. Wrote fancy math on a PhD economist’s laptop. Then when we added testing when developing a platform, we found out we’d been 5% off in allocating Prime revenue between organizations — and had the correct amount gone to Retail, the 2018 hiring freeze might have been avoided. (According to a very angry Wilke.) Whoops. Turned out we did need a team and all those guardrails, processes,…

Did no-one check the maths? There's a difference between having a full test suite, and someone trying some choice values, but I'd expect both would pick up something like that.

Re: Bad scientific code beats code following "best practices" (2014)

#20

Post by arthurcolle »

jurschreuder wrote: post #12

This is so true I don't think I ever read something so true. It's not even scientists vs software developers. It's people who are really into software development and clean code. They say the program needs a total rewrite and proceed to add 20 layers of inheritance and spreading out every function over 8 files. Ever since I make sure to repeat my mantra every week to developers: How maintainable code is is measured i…

works until it doesn't
Post reply on HN