Bad scientific code beats code following "best practices" (2014) • Hacker News Board

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

#231

Post by ameminator » Sat, Jan 06, 2024, 4:15 PM UTC

jampekka wrote: post #195

ameminator wrote: post #194

Earlier quoted context omitted.

> They are also less productive when coding than the scientists because they care too much about the quality of their work and not enough about getting shit done. You can't solve the first 3 issues without having people who care about software quality. People not caring about the quality of the software is what caused those initial 3 problems in the first place.

And you can't fix any of this as long as "software quality" (the "best practices") means byzantine enterprise architecture mammoths that don't even actually fix any of the quality issues.

There are crazy over-engineered solutions with strict requirements and insane dependency management with terrible trade-offs and compromises. I've worked in the aerospace field before, so I've seen how terrible this can be. It's also possible to have unit tests, have a design and have documentation without the above and would go a long way to solve the original 3 issues.

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

#232

Post by esafak » Sat, Jan 06, 2024, 4:16 PM UTC

kolinko wrote: post #160

9dev wrote: post #128

Earlier quoted context omitted.

Don’t think so, no. A physicist has other stuff to learn and spend their time on. Instead, they should partner with a carpenter to do their woodworking from a rough sketch.

It’s like saying that a scientist doesn’t need to know how to write, and they should just pair up with ghostwriters/copywriters. Many professions have tool/skill requirements that are not related to that profession on a strict sense, but are still necessary to do the job properly. When I learned engineering we were taught how to draw diagrams by hand and write in a technical font. Computer code, for many science fiel…

It depends on what you consider a core skill. One has to specialize; that means leaving secondary tasks to others.

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

#233

Post by aleph_minus_one » Sat, Jan 06, 2024, 4:19 PM UTC

movpasd wrote: post #166

jakobnissen wrote: post #141

I'm a scientist programmer working in a field comprised by biologists and computer scientists, and what I've experienced is almost exactly the opposite of the author. I've found the problems that biologists cause are mostly: * Not understanding dependencies, public/private, SCM or versioning, making their own code uninstallable after a few months * Writing completely unreadable code, even to themselves, making it imp…

I work in an R&D environment with a lot of people from scientific backgrounds who have picked up some programming but aren't software people at heart. I couldn't agree more with your assessment, and I say that without any disrespect to their competence. (Though, perhaps with some frustration for having to deal with bad code!) As ever, the best work comes when you're able to have a tight collaboration between a domain…

> As ever, the best work comes when you're able to have a tight collaboration between a domain expert and a maintainability-minded person. This requires humility from both: the expert must see that writing good software is valuable and not an afterthought, and the developer must appreciate that the expert knows more about what's relevant or important than them.

I do work in such an environment (though in some industry, and not in academia).

An important problem in my opinion is that many "many software-minded people" have a very different way of using a computer than typical users, and are always learning/thinking about new things, while the typical user has a much less willingness to be permanently learning (both in their subject matter area and computers).

So, the differences in the mindsets and usage of computers are in my opinion much larger than your post suggest. What you list are in my experience differences that are much easier to resolve, and - if both sides are open - not really a problem practice.

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

#234

Post by Nevermark » Sat, Jan 06, 2024, 4:22 PM UTC

Xeamek wrote: post #92

dmz73 wrote: post #70

Earlier quoted context omitted.

(Ab)use of any paradigm (I'll need a shower for using that word) can result in nightmares. Inheritance has its place and it is definitely useful in more than "few specialised cases". It can get out of hand and it can become a nightmare. Composition has its place and it is definitely not better than inheritance except in "few specialised cases". It can also result in nightmare, just wait till adoption of Rust and go i…

>Writing clean and maintainable code should be the best practice and writing obfuscated code for performance and security should be reserved for "few specialised cases" Except, we can (fairly objectively) reason about performance and security, while 'clean code' and 'maintainability' are arbitrary, with vague guidelines at best. Throwing out those first characteristics in name of the latter ones is just irrational. (…

> Except, we can (fairly objectively) reason about performance and security, while 'clean code' and 'maintainability' are arbitrary, with vague guidelines at best.

Ok, how does one best reason about performance and security with messy unmaintainable code?

You barely need to try even shallow reasoning about a code base at all, before it's clean vs. messy, and maintainable vs. unmaintainable status will feel very objective and pertinent.

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

#235

Post by aleph_minus_one » Sat, Jan 06, 2024, 4:23 PM UTC

hkon wrote: post #222

ameminator wrote: post #194

Earlier quoted context omitted.

> They are also less productive when coding than the scientists because they care too much about the quality of their work and not enough about getting shit done. You can't solve the first 3 issues without having people who care about software quality. People not caring about the quality of the software is what caused those initial 3 problems in the first place.

Yeah, if only scientists would put the same care into the quality of their science...

> Yeah, if only scientists would put the same care into the quality of their science...

I guess we see survivorship bias here: the people who deeply care about the quality of their science instead of bulk producing papers are weeded out from their scientific jobs ... :-( Publish or perish.

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

#236

Post by dijksterhuis » Sat, Jan 06, 2024, 4:24 PM UTC

chaxor wrote: post #207

jakobnissen wrote: post #141

I'm a scientist programmer working in a field comprised by biologists and computer scientists, and what I've experienced is almost exactly the opposite of the author. I've found the problems that biologists cause are mostly: * Not understanding dependencies, public/private, SCM or versioning, making their own code uninstallable after a few months * Writing completely unreadable code, even to themselves, making it imp…

> * Not understanding dependencies, public/private, SCM or versioning, making their own code uninstallable after a few months This is definitely true, but I've searched * far and wide* , and unfortunately it's not a simple task to get this right. Ultimately, if there were a simple way to get data in the correct state in an os-independent, machine independent (from raspberry pi to HPC the code should always work), con…

What you’re describing sounds like DVC (at a higher-ish—80%-solution level although my brain switched off at the mention of IPFS).

https://dvc.org/

See pachyderm too.

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

#237

Post by 9dev » Sat, Jan 06, 2024, 4:33 PM UTC

sidlls wrote: post #170

9dev wrote: post #168

Earlier quoted context omitted.

Now we’re lost in metaphors. A carpenter should definitely be able to build a pergola from a rough paper sketch, and a software engineer should be able to build a machine learning system from an algorithm paper by a data scientist.

That really depends on what you mean by "machine learning system." For a business, implementing some researched algorithm and essentially using a template? Sure, it's possible. The research that goes into producing the algorithm in the first place? Probably not. There may be some classes of scientific programming which have simple enough models for a software engineer to implement. Scientific programming that relies…

Of course it always depends on the context. But my point still stands: a software developer is someone specialising in creating and maintaining code for an application. Any domain knowledge they may need for a particular application doesn’t matter here; their core skill set is software, whereas a scientists core skill set is active research.

Just because some scientific disciplines require extensive programming doesn’t make those scientists good software engineers: Producing an algorithm is different from generating revenue from it.

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

#238

Post by 9dev » Sat, Jan 06, 2024, 4:40 PM UTC

kolinko wrote: post #160

9dev wrote: post #128

Earlier quoted context omitted.

Don’t think so, no. A physicist has other stuff to learn and spend their time on. Instead, they should partner with a carpenter to do their woodworking from a rough sketch.

It’s like saying that a scientist doesn’t need to know how to write, and they should just pair up with ghostwriters/copywriters. Many professions have tool/skill requirements that are not related to that profession on a strict sense, but are still necessary to do the job properly. When I learned engineering we were taught how to draw diagrams by hand and write in a technical font. Computer code, for many science fiel…

> It’s like saying that a scientist doesn’t need to know how to write, and they should just pair up with ghostwriters/copywriters.

And I'd say that illustrates my point even better! A scientist needs to know how to write a paper, but that doesn’t make them a great author. When they aim to write a book, they should get help from a professional publisher. Both tasks require writing text, but a book is very different from a paper and requires heaps of additional training and knowledge that scientists usually don’t need to have.

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

#239

Post by naasking » Sat, Jan 06, 2024, 4:49 PM UTC

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…

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

Trivially false: if all of the source code is kept in one file then you only ever have to edit one file. No matter how many lines of code are in that file, any such system would be maximally maintainable by your definition.

Maintainability is not so clear-cut. It's currently an imprecise measure of organizational clarity that makes it straightforward to extend a system in ways that are needed or will be needed.

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

#240

Post by MrJohz » Sat, Jan 06, 2024, 4:52 PM UTC

jakobnissen wrote: post #141

I'm a scientist programmer working in a field comprised by biologists and computer scientists, and what I've experienced is almost exactly the opposite of the author. I've found the problems that biologists cause are mostly: * Not understanding dependencies, public/private, SCM or versioning, making their own code uninstallable after a few months * Writing completely unreadable code, even to themselves, making it imp…

I only worked briefly in software for research, and what you described matched my experience, but with a couple of caveats.

Firstly, a lot of the programs people were writing were messy, but didn't need to last longer than their current research project. They didn't necessarily need to be maintained long-term, and therefore the mess was often a reasonable trade-off for speed.

Secondly, almost none of the software people had any experience writing code in any industry outside of research. Many of them were quite good programmers, and there were a lot of "hacker" types who would fiddle with stuff in their spare time, but in terms of actual engineering, they had almost no experience. There were a lot of people who were just reciting the best practice rules they'd learned from blog posts, without really having the experience to know where the advice was coming from, or how best to apply it.

The result was often too much focus on easy-to-fix, visible, but ultimately low-impact changes, and a lot of difficulty in looking at the bigger picture issues.