16 ms·
Bad scientific code beats code following "best practices" (2014)
- alexmolas 3y agoNow I dare you to add some new functionality on a bad designed software. Ask a scientist to change a little bit the initial hypothesis and update the code accordingly, and watch them cry while rewriting all the code.
- c048 3y agoThey'll be crying on the same bench as the 'one line of code' people, when they're required to finetune their code.
- palata 3y agoTL;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?
- stalfosknight 3y agoTFA seems to have hit a nerve.
- palata 3y agoIf it's about ranting at classes of people, I can do it too: most software is shit, that's true. But somehow users like shit, and it makes profit so software engineers get paid to write it. They get valued by writing a lot of shit, not by writing little good code. Also most software engineers are juniors; junior civil engineers would not be allowed to build a bridge, junior software engineers can do all the crap they want. But let's be fair: most scientists do bad research. Have you ever read papers in a field you know? 99% is bullshit. Not "non-conclusive good research", no. Downright useless, non-reproducible bullshit (or paraphrasing something that already exists, often making it worse). Just like software engineers, most scientists are juniors (we call them "PhD candidates") who get valued by publishing papers (any paper) in "recognized" journals (with some definition of "recognized"), by journals who make profit by accepting papers (any paper). Again not totally their fault: they have to produce recognized stuff in the time they are given, they don't have to produce good research. I don't have a solution to those problems, of course: that's how the system works ("make profit"). I wish we tried to solve actual problems in a good way, but we don't. I don't think scientists are better than software engineers, though: we are all part of the problem. Less of all of us would make the world a better place (or would have prevented us from spoiling it, at least). I just don't think my rant is worth publishing on HN.
- namaria 3y agoYou 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.
- nvy 3y ago>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.
- namaria 3y agoMaybe by instances of the same codebase, yeah absolutely. But there is certainly more codebases out there running some python or js written by designers, data analysts etc then those produced and curated by software engineers.
- bdowling 3y agoFor every well-engineered application used by millions of users, you've got thousands of poorly-engineered, bespoke applications in use by one or two users (often internal corporate tools or expensive middleware with minimal customization besides changing the corporate branding).
- palata 3y agoStill, I wouldn't consider "Chrome" as good software. Let's be honest: web browsers are really bad. Overly complicated machines made to print images and text on the screen. The web got sideways long ago, first because it was cool to add crap in websites, then because it made profit and allowed monopolies to make more profit by moving everything to damn webapps. And finally it allows companies to screw users by renting software on the damn cloud. And they profit by making it as accessible as possible, such that everyone and their dog can produce a crappy webapp that will show their ads or track their users. Webtech is part of what makes software really bad, even if it was created by good engineers. Because people don't want quality: they want cheap new crap.
- aragilar 3y agoBad code written by software engineers is worse than bad code written by scientists, as the former takes more effort to fix than the latter (given the pathologies mentioned). It's naturally preferable to not have bad code, but it that choice was actually on the table, then I don't know who would choose the bad code. As for hiring software devs, that's not going to change (in general, there are places where software devs write code used by scientists, but rarely are these codes themselves pushing research boundaries, it's code on top it that does) absent significant changes in funding structure and rules (which are typically a government/public service concern, and not up to researchers).
- Faark 3y ago> as the former takes more effort to fix than the latter Disagree. Well, maybe still acceptable if the software is small / limited to a single paper. Having worked on a code base the people writing it learned programming on that job, guessing their intention is like archeology. And each iteration tended to add some complicated interdependence. Or like when int errorCode came from other, overlapping error ranges. A part of the "new" code base is exactly as described by TFA. Including most interfaces having only one implementation. But while annoying, I am more able to work on it without things breaking...
- palata 3y agoIt's just comparing two different things: the average "bad code from scientist" is for simple tasks, whereas the average "bad code from software engineer" is for a complicated task (otherwise you shouldn't pay the software engineer in the first place). My point about the rant being counter-productive is that the solution is to learn how to do the task better, not to blame people. Maybe the best way to do a task with a very low budget is to not do it at all.
- nottorp 3y agoOP may have not clicked on the rest of the blog...
- bearsnowstorm 3y agoRead this on mobile and the identifier longWindedNameThatYouCantReallyReadBTWProgrammersDoThatALotToo overflowed into the margins - I regard this not as a bug but a feature which helped make the author’s point :-)
- _the_inflator 3y agoThat’s why I fell in love with Objective C. The libraries used a lot of those expressive descriptions for attributes and methods. I never understood nor understand people who nest their inner loops in an entangled mess of hardly distinguishable digits, which is error prone. Same for method names. I try to use speaking out loud to some of my methods: What do you do? And if the answer is getValue I believe it needs renaming.
- mxmbrb 3y agoWe use this technique as a guide in our company. If someone (knowledgable) would ask "What does this method call do?" and the method name does not answer that, your PR doesn't go in the master. E.g. getString(path) for loadConnectionStringFromDisk(configFilePath), tryConnect(30) for testSqlConnection(timeoutInSec), even the reader now knows what happens here and what input is expected.
- nickm12 3y ago> I've been working, ... in an environment dominated by people with a background in math or physics who often have sparse knowledge of "software engineering". ... Invariably, the biggest messes are made by the minority of people who do define themselves as programmers. Interesting switch in language here from "software engineering" to "programmers". There is of course a long history of debate on these terms, whether there is a meaningful distinction, and what qualifies as engineering versus programming. Wherever you stand on this debate, there are a number of practices of software developers that tend to be used more towards the "engineering" side. Two of the most essential in my mind are peer code reviews and automated testing of changes (with tests, linters, type-checkers, code formatters, profilers, fuzzers, etc.). This post doesn't talk about any of these practices or whether the so-called "programmers" messing up the scientific code are using them. I'd say if the people messing up the code are not actually advocating for using software development tools to write better code they are not actually applying software engineering practices to their code.
- palata 3y agoI would never call myself "electrical engineer" or "mechanical engineer" because I did not study that. But everyone who is paid to write some amount of code calls themselves "software engineer". Not sure how much of a problem it is, but I am frustrated when "other" engineers try to teach me about how networking works and never once consider that my intuition may possibly have more value than theirs, because I actually studied networking. Not that I am always right of course, but if we have an electrical engineering argument, I naturally get into a stance where I assume they know better and can teach me useful stuff.
- fulafel 3y ago> 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 making a big deal out of it. You get organizational clout and inertia on your side when you make something big and expensive. And then complex systems are by nature hard to reason about and by extension hard to critique. So many things come down to "complexity is the enemy".
- zmgsabst 3y agoPrime 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, code reviews, etc. There’s a time and a place for “move fast and break things” — but real trouble can come from taking those academic practices into the real world.
- aragilar 3y agoDid 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.
- adrianN 3y agoIf simple checks could find all bugs we would not have so much buggy software.
- zmgsabst 3y agoThe PhD economists on our team looked at it. Economists from other teams looked at it and signed off. There was manual testing — ie, trying some “choice values”. We discovered their error in convexity when our test suite allowed us to randomly sample the models at scale. (Actually, I had questions before that — but unsurprisingly, when it was just me questioning a PhD economist, the lowly SDE was ignored.) Good intentions aren’t enough; you need mechanisms.
- jayd16 3y agoIf 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.
- InSteady 3y agoThe 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.
- jayd16 3y agoThey state clearly that they can't follow the call structures and often give up on understanding them.
- aragilar 3y agoDefine "correctness bugs". Does the code leak memory (which is not ideal)? That's only an issue for the scientist if it prevents/invalidates the science. But if the pattern hides how something is expressed, or someone unfamiliar with the science tries refactoring the code, that's more likely to cause issues with the science than the memory leak.
- jayd16 3y ago> Access all over the place – globals/singletons, "god objects" etc. Crashes (null pointers, bounds errors), largely mitigated by valgrind/massive testing Complete lack of interest in parallelism bugs (almost fully mitigated by tools)
- scj 3y agoBest practices tend to be overkill for small codebases that have few users, which encompasses the majority of scientific code. Sheer tenacity is typically sufficient for scientific codebases.
- jurschreuder 3y agoThis 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.
- erhaetherth 3y agoThat's a slippery mantra. I can see putting everything in one file.
- jampekka 3y agoEverything in one file can be good organization for many even relatively large projects.
- arthurcolle 3y agoworks until it doesn't
- canpolat 3y agoWorking with a 300 line method is not fun, believe me. Everything is in one place and you don't have to change many files, yes, but due to the cognitive load, it's so much more effort to maintain it.
- __loam 3y agoThere's a happy middle path here I think. Long functions are hard to grok. Spreading the logic across 20 files also increases cognitive load. There's a balance to strike.
- galaxyLogic 3y agoRight, but the article seems to imply that all code should be in a single file. It seems the author indeed is not a SW Engineer and thus does not really grok the benefit of "modules". This of course depends on the size of the program. Small program "fits" into a single module. And I think that scientific programs are basically small and simple because they don't typically need to deal with user-interaction at all, they just need to calculate a result. Further I think scientific programs rely heavily on existing libraries, and writing a program that relies heavily on calls to external libraries produces simple, short programs. Scientists produce science, engineers produce code-libraries.
- briantakita 3y agoSome 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.
- cube00 3y agoWhen scientific code is not required to be published with its research literature who really knows how bad it is?
- bsdpufferfish 3y agoA few responses come to mind. Who is requiring? What counts as code that needs to be published? But perhaps the most relevant response is that few people read papers, even fewer are going to look into their zip. The whole idea of papers is to condense a whole lot of work into concise digestible information.
- maximus-decimus 3y agoAren't papers also supposed to be reproducible? Having access to the original code would allow you to see why you're not getting the same results if it's caused by a bug.
- gregopet 3y agoSounds like the non-programmers are good at what they are supposed to be good at (solving the actual problem, if perhaps not always in the most elegant manner) while the programmers should be producing a highly maintainable, understandable, testable and reliable code base (and potentially have problems with advanced algorithms that rely on complicated theorems), but they are not. The OP has a case of bad programmers - the techniques listed as bad can be awesome if used with prudence. A good programmer has a very deep knowledge of the various techniques they can use and the wisdom to actually choose the right ones in a given situation. The bad programmers learn a few techniques and apply them everywhere, no matter what they're working on, with whom they are working with. Good programmers learn from their mistakes and adapt, bad programmers blame others. I've worked with my share of bad programmers and they really suck. A good programmer's code is a joy to work with.
- galaxyLogic 3y agoRight and I think "scientists" simply are more intelligent than average Joe Coder. Intelligent people produce better software. It is easy to learn some coding, not so easy to become a scientist. To becomes a scientist you must write and get your PhD-thesis approved, which must already be about scientific discoveries you have made while doing that thesis. Only people with above average IQ can accomplish something like that, I think.
- palata 3y ago> Right and I think "scientists" simply are more intelligent than average Joe Coder. Intelligent people produce better software. The vast majority of papers I read on topics I know are complete bullshit. Maybe making a PhD was more elitist before, but now it surely isn't. If we define "scientist" as anyone who publishes papers, then they have the same problem as software engineering: it's mostly made by juniors.
- _Wintermute 3y agoIn my experience getting a PhD doesn't require above average intelligence, it does require a lot of perseverance and a good amount of organisation though. I honestly think most skilled tradespeople are more intelligent than me and my PhD holding colleagues.
- quirkot 3y agoGood code is the simplest code you can write to get the job done. Getting too excited about techniques is a form of scope creep
- charlieyu1 3y agoIt depends on what it means to be to get the job done. Write some code and generate immediate results can be considered a done job. If you want to reuse the code a year later and found an unreadable mess though, not so much.
- rukshn 3y agoA former physicist at our organization wrote a tool t convert a diagram into an algorithm in a domain specific language. He made it to make his own life easier, and never considered any best practices, everything was a thousands of lines of jupyter notebook, it was not modular, painful to customize but just got the work done, and was kinda a black box in way the way it generated the outputs. Since then we've tried to re-write it with good programming principles, but still we were not able to re-create what he did. So yah sometimes done is better than perfect.
- wilg 3y agoIs this article just two strawmen fighting?
- laserbeam 3y agoI agree with the feelings of the author, most software is overengineered (including most of my software). That being said, most scientific code I've encountered doesn't compile/run. It ran once at some point, it produced results, it worked for the authors and published a paper. The goal for that code was satisfied and than that code somehow rusted out (doesn't work with other compilers, hadn't properly documented how it gets build, unclear what dependencies were used, dependencies were preprocessed at some point and you can't find the preprocessed versions anywhere to reproduce the code, has hardcoded data files which are not in the published repos etc.). I wouldn't use THAT as my compass on how to write higher quality code.
- ShamelessC 3y agoYeah somehow I suspect this author hadn't yet had to deal with colab notebooks.
- noobermin 3y agoYeah, well gnome 2 also doesn't compile or run on my machine. It ran once at some point, but one is considered a "worse" class of software.
- a-dub 3y agonumerical code isn't like application code. the rules of application code don't always apply. for example, i think one character variable names are totally fine if they come from equations or papers where in most applications it's generally frowned upon. this is why i'm a little skeptical of languages that blur the lines. sometimes ideas from application programming can complicate numerical code and sometimes numerical programmers don't fully understand the systems abstractions they're building on and end up reinventing wheels to avoid simpler solutions they feared or didn't know existed. the moral of the story is to keep an open mind, to not be a zealot and to avoid dogmatic thinking.
- YouWhy 3y agoI think we have a case of survivorship bias. A considerable majority of the science-non-SWE crowd are de facto incapable of writing more than 100 lines of runs-in-my-notebook code. Hence, if a change/bug is necessary, it is much likelier to fall under a SWE jurisdiction, and hence is much more likely to be industrial code. Add to that a further confounder (tiptoeing a "no true Scotsman" here): academia is not a first choice of workplace for strong SWEs.
- hannofcart 3y agoI'm not so sure that this claim is valid as a general observation. Multiple times in my career, I have seen scientific code written by academics dramatically sped up by developers who used parallelisation, vectorisation using SIMD etc. So in terms of performance, naively written scientific code is generally easy to beat in terms of performance for a reasonably adept programmer. That said, "enterprisey" Java/.NET software engineering shops can indeed make scientific code sub-optimal sometimes. Have come across that sometimes too but I wouldn't generalize.
- lll-o-lll 3y agoMeh. Who actually works as a software dev at one of these academic institutions? The pay is beyond terrible. Presumably you have either: - Young and keen. Young and keen are the source of all kinds of terrible things. That’s why you need old and bitter to balance it out. Old and bitter is off working for much more money in a boring corporate. - Side hustlers/other incompetents. “I’m now a software dev!” It’s not that proper software shops don’t struggle against “complexification” and all manner of other deviant behaviours. There are so many ways to turn software into hell - “All happy families are alike; each unhappy family is unhappy in its own way.” But if this is your problem, the problem isn’t “the software industry” or “best practice” or “devs jobs are so easy they just have to make up complexity”. The problem is incompetence. Managerial/leadership incompetence.
- jusssi 3y agoTwo more to the scientists' tab: 1. No tests of any kind. "I know what the output should look like." Over time people who know what it should look like leave, and then it's untouchable. 2. No regard to the physical limits of hardware. "We can always get more RAM on everyone's laptops, right?". (You wouldn't need to if you just processed the JSONs one at a time, instead of first loading all of them to the memory and then processing them one at a time.) Also the engineers' tab has a strong smell of junior in it. When you have spent some time maintaining such code, you'll learn not to make that same mess yourself. (You'll overcorrect and make another, novel kind of mess; some iterations are required to get it right.)
- Asraelite 3y agoAgree with those two problems on the scientist side. I would also add that they often don't use version control. I think a single semester of learning the basics of software development best practices would save a lot of time and effort in the long term if it was included in physics/maths university courses.
- squarepizza 3y ago> I would also add that they often don't use version control. Working for corporate R&D, I once received a repo on a flash drive. The team would merge changes manually by copy-pasting. I should've just turned around and left.
- lozenge 3y agoYes, the claim that the scientists' hacked-together code is well tested and even uses valgrind gave me pause. It's more likely there are no tests at all. They made a change, they saw that a linear graph became exponential, and they went bug hunting. But there's no way they have spotted every regression caused by every change.
- 2devnull 3y ago1 and 2 are features. Re 1, if someone doesn’t know what the output should look like they shouldn’t be reusing the code. Re 2, just think a bit more about it and you’ll realize fretting over ram that isn’t needed until it’s needed is actually just premature optimization.
- LudwigNagasena 3y agoI will believe that when scientists will stop being too embarrassed to publish their code. Do people not remember mrc-ide/covid-sim?
- esafak 3y agoNo?
- dang 3y agoRelated: Why bad scientific code beats code following “best practices” (2014) - https://news.ycombinator.com/item?id=12377385 https://news.ycombinator.com/item?id=12377385 - Aug 2016 (261 comments) Why bad scientific code beats code following "best practices" - https://news.ycombinator.com/item?id=7731624 https://news.ycombinator.com/item?id=7731624 - May 2014 (168 comments)
- cnewey 3y agoWhile I think there are a couple of valid points, in general my feeling is that the author is setting up a straw man to attack. Most of the “programmer sins” are of the type that more seasoned engineers will easily avoid, especially those with experience working with scientific code. Most of these mistakes are traps I see junior developers falling into because of inexperience.
- 9dev 3y agoOh look, another tiring craftsmanship debate that other disciplines long figured out! A, say, physicist writing bad code could equally well be building a pergola for his garden. He doesn’t really know woodworking but god be damned if he couldn’t calculate the forces acting on the beams, and then add some screws - how hard can it be! And probably, he’ll even get the thing up, and it doesn’t look too bad even. Now get a carpenter over, and they will be horrified about all the things the scientist did unusually, did not account for, or just plain wrong. ”Wall Screws you still had around?? How could you not know you’d need structural screws for that?“, he will scream. However, the thing does roughly what the scientist supposed it should do. Until the winter, that is, when the wood expands due to humidity and cracks appear, and he finally needs a professional to fix the problems. It’s the same story, really: It is a software engineer’s job to build quality software. A scientists job is to solve problems. There’s a clear boundary here, where the latter will deliver a concept to the former, who will eventually create a production-grade implementation off of that. Neither does a scientist have to build proper software, nor does a developer have to do cutting-edge research. And all the words wasted on how one of them might be doing something badly is on he wrong path.
- chongli 3y agoThe real difference here is between hobbyists and mere workers. Programming happens to be one of the disciplines which has a lot of hobbyists. But that doesn’t mean you won’t find hobbyists in other disciplines. Look at machining for example. Long dominated by people working in machine shops making tools and parts on the clock. But in the background there’s a strong hobbyist contingent and there you’ll find endless debates over whether a beginner should buy a decades old Bridgeport milling machine or a brand new Chinese-made one. Similarly I find endless debates about what sort of frying pan to use (nonstick, stainless, carbon steel, or cast iron) among amateur chefs, but you’ll never see people working in a restaurant waste time on that. In other words, it’s hobbyists who really obsess over tools and craftsmanship. They do it because they love it. Programmers just happen to be among the odd sort who can get paid to practice their hobby.
- esafak 3y agoI don't know about that. Pros obsess over it too, but they don't bother to endlessly talk about it; they just do it. But if a better tool comes along, they'll consider it.
- Roark66 3y ago>Multiple/virtual/high-on-crack inheritance 7 to 14 stack frames composed principally of thin wrappers, some of them function pointers/virtual functions, possibly inside interrupt handlers or what-not Files spread in umpteen directories Scientific code? You just described 99% of "enterprise" java code above.
- 59nadir 3y agoThat's from the list of software engineer sins, yes, so that tracks with your opinion.
- MichaelRo 3y agoI've seen this: - Multiple/virtual/high-on-crack inheritance: add each function/class has 7 template specialization parameters and 3 macros which expand to templates which expand to macros - Lookup using dynamic structures from hell – dictionaries of names where the names are concatenated from various pieces at runtime, etc. think maps of maps of maps loaded from configs of configs - Dynamic loading and other grep-defeating techniques obviously everything has to be a "plugin" - A forest of near-identical names along the lines of DriverController, ControllerManager, DriverManager, ManagerController, controlDriver ad infinitum – all calling each other a 1000 times yes! yes!!! DriverController inherits from ControllerManager which extends ManagerController which contains a DriverManager which agregates 3 ControllerManager from diferent namespaces. I've seen a DriverController function going through 12 levels of stack passed between 3 threads to eventually call back a function from the same DriverController - Templates calling overloaded functions with declarations hopefully visible where the template is defined, maybe not if a template technique exists, it had to be used! - Decorators, metaclasses, code generation, etc. etc. Of course they define their own DDL with xmls parsed by a combination of Python and awk which generates C++ macros which are used in templates to dynamically load plugins which hold maps of maps of function pointers to create3 events dispatched on a pool of threads
- Poliorcetes 3y agoreminds me of java spring library and on top of it those DriverControllers and ManagerControllers keep getting depracated
- Nursie 3y agoYeah nah. There was the flawed model out of Imperial College (IIRC) during the early covid days that showed up how wrong this attitude is. It was so poorly written that the results were effectively useless and non-deterministic. When this news came out, the scientists involved doubled down and instead of admitting that coding might be hard, and getting in a few experts to help out might be useful, actually blamed software engineers for how hard it is to use C++.
- astrobe_ 3y agoThis is partly because, in my opinion, some "best practices" are superstitions. Some practice was best because of some issue with 80s era computing, but is now completely obsolete; problem has been solved in better ways or has completely disappeared thanks e.g. to better tooling or better, well, practices. e.g. Hungarian notation. Yet it is still passed down as a best practice and followed blindly because that's what they teach in schools. But nobody can tell why it is "good", because it is actually not relevant anymore. Scientific code has no superstitions (as expected I would say), but not for the best reasons; they didn't learn the still relevant good practices either.
- DragonStrength 3y agoActually, when I’ve followed those guidelines, it’s because the tech lead graduated in the 1980s, almost certainly learned it all on the job, but has always done it that way. Others just do what they’ve done before. School talked about those things, but not in a “this is the right way” sort of thing.
- tchalla 3y agoI wish we communicated the intent of the “best practice” instead of the practice itself.
- quickthrower2 3y agoThere is no best practice. It is good to know the tools. In dojo, do that crazy design pattern shit and do crazy one long function. Do some C#, Java, JS, Go, Typescript, Haskell, Ruby, Rust (not necessarily those but a big variety). I want the next person to understand my code - this is very important. Probably more important than time spent or performance. If spending another 10% refactoring to make it easier to understand, even if just adding good comments, it is well worth it. Make illegal state impossible, if you can (e.g. don't store the calculated value, and if you do then design it so it can't be wrong!). Make it robust. Pretend it'll page you at 2am if it breaks!
- ohlokkru 3y ago[flagged]
- Spiwux 3y agoI really do not understand these memes about overengineered FactoryFactoryFactories. I have 10 YOE, did I just get lucky? I've worked at enterprise Java shops as well, but even there I'd call the software pragmatic. Are these overengineered monstrosities REALLY still a thing, or is it "just" people suffering in legacy projects? Even the juniors I worked with were following KISS and YAGNI.
- _v7gu 3y agoYes, some people read Clean Code and think every file should have less than 20 lines. I recently inherited a React project that has all single-use utility functions, graphql queries and component types extracted out to different files. Having to edit five+ files to change things in one component is a nightmare experience and slows down changes a lot.
- davedx 3y agoYeah I think in the last 10 years things have definitely changed. One of the last Java projects I worked on was in 2013 and the lead was ex-Google; he deliberately pulled in the simplest Java libs to get the job done and we didn’t over engineer anything. Contrast that with 1990-2010, the era of struts and enterprise java beans, things were definitely different back then.
- dash2 3y agoUlp. As a scientist who is a hobby "programmer", this struck close to home. I've got one project[1] with a huge mess of functions calling each other. It started out with good intentions, but then gradually descended as I wrote more and more hacks to add new analyses & robustness checks. I swear I meant well! I think there's a genuine tension between writing good code and "shipping" a paper. At least, when I program "as a programmer" I think my code is mostly higher quality. [1] https://github.com/hughjonesd/why-natural-selection/blob/master/_drake.R https://github.com/hughjonesd/why-natural-selection/blob/mas...
- zeraholladay 3y agoI think a lot of developers naively rely on "software design" principles. They often can't state their reasons for adopting these principles and assume these principles are self-evident. This can be a problem when these principles conflict with external priorities, or when a complex "principled" design is used instead of an obvious, intuitive design. There's also a certain amount of trendiness to software design, so trends can be applied haphazardly. That being said, I've also seen plenty of "scientific code" that's totally incomprehensible even to the point where the scientist who wrote the code can't debug it. So there's an extreme in the other direction.
- renewiltord 3y agoCost is paid during development and maintenance. Value is reaped during usable life. The two periods overlap. Then subtract value from cost and integrate. Maximize that number. Easily leads to conclusions of "you don't need this to scale" vs "build this to scale" and "you need to make this extensible" vs "just ship the hacky thing". Just need to know what your params are and place uncertainty on it. Once I wrote a program in a day. Did a kind of pricing. Hacky af. Just tech demo. Over time people start depending on it. One year later it breaks. Too many products priced, internal ring buffer only has few slots. Pricing stalls for all products. "This is a company-killing issue!" Everyone yells. Sure, my mistake. I let thing get depended on without productifying but original choice was fine since it allowed iteration on something else that made money. Just when situation changes you gotta adapt. No rules about that except just short loop on quality required and time spent.
- puttycat 3y agoOP is using a strawman caricature of a programmer to make his point. While such bad (often junior) programmers exist, there also exist many reasonable ones who won’t commit all these over the top abstractions while also not falling into the "scientific" programming pathologies.
- ben_w 3y ago> Many programmers have no real substance in their work – the job is trivial – so they have too much time on their hands, which they use to dwell on "API design" and thus monstrosities are born. Definitely getting this vibe from modern frameworks and design patterns. I want to like SwiftUI, but the WYSIWYG editor doesn't even work for the default projects for me. Storyboards were great for creating everything UI except tables and collections, where it was still functional just meh. The reactive UI in SwiftUI… mostly works, but sometimes doesn't, and when it doesn't I can't debug it because it's a magic black box; you can get similar results with a small amount of extra code in UIKit { didSet } on your model property and each input control, and while boilerplate isn't great, it's better than magic which only works 98% of the time. I'm trying things in JS in my spare time, no libraries or frameworks, and it's easier and faster than getting anything done in XCode. And that's despite the Swift language itself being one I prefer over JS, and that I'm doing the development in BBEdit which is a text editor not a full IDE. But this isn't just about Apple; the reason I'm not using any JS framework and libraries is that every single talk I've seen about web development has exactly the same problem, piling on layers of stuff to fill in the gaps missed (or created) by the previous layer of abstraction.
- palata 3y ago> piling on layers of stuff to fill in the gaps missed (or created) by the previous layer of abstraction. I think the goal is to make if more accessible, so that more people with less knowledge can produce more crap with it. People don't learn the basics, they want to write a comment in Copilot and have it assemble code that roughly does what they want. I believe that people who got into software in the 60s actually liked computers. People who get into software today just want to produce stuff, they don't care about their computer.
- ben_w 3y ago> I think the goal is to make if more accessible, so that more people with less knowledge can produce more crap with it. If so, it fails at even this: for my A-levels[0], my teacher only knew VisualBasic[1], which was very easy to work with: drag and drop widgets onto a form, (double?)-click on a widget to get right into the code block that happens when a user users the widget. Back when JS was new and there were no extra layers of abstraction, yes the language sucks, but you could get to work with it using only what you found in a £4.99 book from WHSmith[2] and a text editor, you didn't need to `install npm` and then some library and then… > People don't learn the basics, they want to write a comment in Copilot and have it assemble code that roughly does what they want. Agree. Heck, I do that, and I started learning the basics when I was about 5. :) > People don't learn the basics, they want to write a comment in Copilot and have it assemble code that roughly does what they want. I believe that people who got into software in the 60s actually liked computers. People who get into software today just want to produce stuff, they don't care about their computer. My dad probably got into computers some time in the 60s, a one or two day corporate training program about "this new thing called 'software'". The way he talked about them, it was clear he didn't really understand them, and just wanted to get stuff done. [0] https://en.wikipedia.org/wiki/A-level https://en.wikipedia.org/wiki/A-level [1] It turned out that the copy of REALbasic I had on my Mac at home was almost copy-paste compatible, the only exception I ran into was that `Dim foo, bar As Integer` has `foo` and `bar` being `Integer` in REALbasic while our version of VB had `foo` being `Integer` and `bar` being `VarType` [2] https://en.wikipedia.org/wiki/WHSmith https://en.wikipedia.org/wiki/WHSmith
- fifilura 3y agoThis is the battle I am currently fighting. Specifically when working with numbers (something scientists do), i feel it is more important to know the numbers and have an intuition of what is important to get right and what is less important. Rather than spreading unit tests and the following abstractions all over the place. But scientists can create a hot mess too. This is when they don't care about the code enough to minify it. I.e. reducing the code to what is necessary. Number of lines of code matter. So the perfect blend here is not necessarily the person that follows all engineering practices. But the person has the domain knowledge but that knows enough about software practices to be able to write concise code. If you are either missing out on the domain knowledge - or the ability to reduce the code - then it will derail. Shipping the notebook to engineering department will not be the solution. They will break the code into pieces, follow best practices but miss out on the important. And another aspect of this practice is that if someone finds a problem, the scientist will not be able to modify or re-run the engineered version of the notebook.
- quickthrower2 3y agoI agree. Been doing devops recently but back at some coding at work and I wrote the function as simple as I could, adding complexity but only as needed. So it started as a MVC controller function that was as long as your arm. Then it got split up into separate functions, and eventually I moved those functions to another file. I had some genuine need for async, so added some stuff to deal with that, timeouts, error handling etc. But I hopefully created code that is easy to understand, easy to debug/change. I think years ago I would have used a design pattern. Definitely a bridge - because that would impress Kent Beck or Martin Fowler! But now I just want to get the job done, and the code to tell a story. I think I pretend I am a Go programmer even if I am not using Go!
- c048 3y agoCongrats, you used design patterns.
- quickthrower2 3y agoStill have the self made pat on my back
- r9295 3y agoI wonder why people complain about the replication crisis.
- deleted 3y ago[deleted]
- austin-cheney 3y ago> Invariably, the biggest messes are made by the minority of people who do define themselves as programmers. After 15 years of writing JavaScript professionally I know that is a lie. The biggest messes are made by the majority of people hired that cannot really program.
- fsloth 3y agoI guess this could be an economics thing. Stereotypically maintenance of scientific codebases in general is not very lucractive, and the mental kick (IMHO you need to enjoy high performance numerical computing to be truly good at it) can be had for much better compensation doing stuff like cad or game engines. So I would imagine if the author has lots of experience of "professional programmers" maintaining their scientific codebase the talent pool from which they are sampled is not necessarily optimal for high output individual contributors. My intent is not to put down maintainers of scientific software! It's super cool and super important. I see the damage a person decades in an industry can do when they cluelessly and energetically start to test and implement a new shiny thing on an industrial codebase. When the product brings in hundreds of millions a year, there is incentive to patch up the damage so you can have future releases and continue the business. I'm not sure how much resources a scientific codebase maintenance could use just to patch up a mountain of architectural and runtime damage.
- austin-cheney 3y agoThe goal of 95% of JavaScript in the wild is as mild as respond to user interactions and put text on screen. Its beyond trivial simple, but almost nobody is well trained to either the language or browser. As a result most people come in with assumptions of how things should work as determined by their education or experiences in unrelated languages and boy are most of those assumptions wildly incorrect. On top of that most JS developers tend to skew extremely young and are wildly insecure about complex data structures. The result is a complete inability to program. Most people need really large tools to do more than 80% of the heavy lifting and they just write a few instructions on top of it. The perspective then becomes you need more advanced technologies to do cool things, because everything is too scary or mysterious otherwise.
- Yasuraka 3y agoJava and its consequences have been a disaster for the human race.
- niemandhier 3y agoScientific programming and industry programming are distinct disciplines. For scientific code certain things are just not important, hence you do not deal with them: - Observability: You just care for the result of the run, not for the state of the running system - Security: Your code is running in isolation, used by yourself The result looks horrible to a normal programmer, even if it’s well maintainable, but it is exactly what is needed to do the job.
- mike_hearn 3y agoNo it isn't and this idea needs to die. Sure, you can ignore security if all you're doing is processing local text files, granted. But things looking horrible to programmers isn't just about security bugs, it's about the whole span of correctness bugs. And scientists need to write code that is both correct and maintainable. The frequency with which they don't is partly why results so often can't be replicated, making the money spent on academia wasted. The idea that science code doesn't need to be maintainable or that they have some magic way to do it that looks wrong, isn't right either. It's not uncommon to find model "codes" that scientists have been hacking on for decades. The results have become completely untrustworthy many years earlier, but they deny/obfuscate/ignore, attack or even sue people who point out concrete problems. Sadly, often with the acquiescence of the media who are supposed to be ferreting out coverups. Scientists need to collectively get a grip on this situation. They will happily attack anyone outside their institutions as being non-expert conspiracy theorists, but when it comes to software they suddenly know everything and don't need to hire professionals. Paper-invalidating bugs are constantly being covered up and the only reason the problem hasn't reached criticality yet is that many people don't want to hear about it. But the unreliability of academic output is now becoming a political problem and a divisive culture war issue, when it really shouldn't be. A good first step to solving the replication crisis would be for scientists to stop pretending it's OK to quickly knock together a program themselves instead of assigning a ticket to a trained full time SWE. Yes it would cost more (a lot more), and that's OK. Generate fewer papers but get them right!
- jakobnissen 3y agoI'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 impossible to maintain. This means they always restart from zero, and projects grow into folders of a hundred individual scripts with no order, depending on files that no longer exists * Foregoing any kind of testing or quality control, making real and nasty bugs rampant. IMO the main issue with the software people in our field (of which I am one, even though I'm formally trained in biology) is that they are less interested in biology than in programming, so they are bad at choosing which scientific problems to solve. 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.
- op00to 3y agoThis was my exact experience working in biomedical hpc.
- civilized 3y agoThese patterns appear in many fields. I take it as a sign that the tooling in the field is underdeveloped. This leads to a split between domain problem solvers, who are driven to solve the field's actual problems at all costs (including unreliable code that produces false results) and software engineers, who keep things tidy but are too risk-averse to attempt any real problems. I encourage folks with interests in both software and an area of application to look at what Hadley Wickham did for tabular data analysis and think about what it would look like to do that for your field.
- pas 3y agojournals, research universities/institutions, and grant orgs have the resources and gatekeeping role to encourage and enforce standards, train and support investigators in conducting real science not just pseudoscience, but these entities are actively disowning their responsibility in the name of empty "empowerment" (of course because rationally no one has a real chance of successfully pushing through a reform, so the smart choice is to just not rock the boat)
- collyw 3y agoWorst code I have seen has been written by self taught bioinformaticians. But, a lot of the time these scripts are used as one offs, to generate a result, then are done with, so quality doesn't need to be the same as with a server running 24/7.(Sadly the ones I had to fix were being run regularly).
- amadeuspagel 3y ago> Files spread in umpteen directories Tools and frameworks encourage this. Git and VS code are build around directories. In VS code the first thing in the sidebar is the explorer. When you press Ctrl+P you see an overview of files. File-System based routing. But directories lack a crucial feature compared to text: Ordering. If I put everything in one file, I can order it in a way that makes sense. If I put everything in different files and directories, it's all going to be ordered alphabetically.
- dkarl 3y agoProgrammers want to embed domain terms everywhere. They look at scientific code and expect to see variables names containing "gravity," "velocity," etc. Scientists need code to conform to the way they examine, solve, and communicate problems. I asked for an explanation of a particular function and was sent a PDF and was told to look at a certain page, where I found a sequence of formulas. All of the notation matched up, with the exception that superscripts and subscripts could not be distinguished in the code. To a programmer, the code looked like gibberish. To the scientists working on the code, it looked like a standard solution to a problem, or at least the best approximation that could be given in code. You see the inverse problem when it comes to structuring code and projects: programmers see standard structures, expected and therefore transparent; scientists see gibberish. Scientists look at a directory called "tests" and think of a variety of possible meanings of the word, none of them what the programmer intended.
- esafak 3y agoThe programmer's naming approach has the virtue of being self-explanatory, and thus more maintainable. Scientists don't care about maintainability. Their bar is reproducibility, and even for that they don't expect it to be as painless as an automated test.
- analog31 3y agoI'm a scientific coder, though I work in industrial R&D feeding product development. My work doesn't get published. I've studied good programming practices for 40 years, and I try to behave myself. One thing I've noticed is that programming practices have evolved, not so much to make them better than before, though that's conceivable. But because practices have to keep up with rising complexity of the code itself, and also of the operating environment and the social environment (e.g., work teams, open source projects, etc). Scientific programs tend to be easily 20 years behind software development in terms of complexity, and I think we can benefit from using older techniques that were simpler and easier to learn. I learned "structured programming" via Pascal, and to this day if I hew to the same practices that I learned in my Pascal textbook, my program will probably do what it needs to do and be tolerably maintainable. Perhaps those practices have to come from the mouths of scientists. The software engineers have moved on, and are only interested in the latest and greatest toys. I don't blame them -- they have to own their careers and follow their interests just like we do. I mentor younger scientists who come out of fields such as chemistry, and are beginners at coding. So I literally get to explain such basic things as putting code inside subroutines, and avoiding global variables. I haven't had to tell anybody about GOTO's yet. About reproducibility: My parents were both scientists, though my mom spent a few years in mid-career teaching programming at a community college. I learned the scientific method sitting on my mommy's knee. "Reproducibility" was certainly a guiding principle, but it was also expected that reproducing a result would require some effort -- perhaps fabricating your own equipment from available materials, and gaining skill on a technique. You might get it wrong many times before finally getting it right. What we expect now is "pushbutton" reproducibility, meaning that a project replicates itself from start to finish at the push of a button. This is a much higher standard than any scientist is trained to expect, even if software engineering requires it. A software project has to be at least 99% that way, or it would be unworkable, due to the high degree of complexity. The tradeoff is that it also requires complexity to make things that way. I expect my results to be reproducible, but not pushbutton-reproducible. To overcome this issue, I'd rather spend my time documenting my code and its theory of operation, than making it bulletproof. Nothing that I write goes directly into production, and I expect the theory of operation to be more valuable to a project than my code. Often, the code just automates an experiment to test the theory, so it's a middleman rather than a product.
- jmilloy 3y agoFortunately the list of "bad" code features attributed to each group is listed clearly. The title simply needs to read "Bad scientist code beats bad programmer code", or "A list of bad practices that programmers often think are good".
- dahart 3y agoIn other words, programmers tend to over-engineer, and non-programmers tend to under-engineer. Despite all the arguments here about who’s making the biggest messes, that part is not surprising at all. Both are real problems. Over-abstraction and over-engineering can be very expensive up front and along the way, and we do a lot of it, right? Under-engineering is cheaper up front but can cause emergencies or cost a lot later. Just-right engineering is really hard to do and rarely ever happens because we never know in advance exactly what our requirements and data really are. The big question I have about scientific environments is why there isn’t more pair-programming between a scientist and a programmer? Wouldn’t having both types of expertise vetting every line of code be better than having each person over/under separately? Ultimately software is written by teams, and it’s not fair to point fingers at individuals for doing the wrong amount of engineering, it’s up to the entire team to have a process that catches the wrong abstraction level before it goes too far.
- lynndotpy 3y agoScientist and programmer here, and my experiences are the opposite. I value keeping things "boringly simple", but I desperately wish there was any kind of engineering discipline. First is the reproducibility issue. I think I've spent about as much time simply _trying_ to get the dependencies of research code to run as I have done writing or doing research in my PhD. The simple thing is to write a requirements.txt file! (For Python, at least.) Second, two anecdotes where not following best practices ruined the correctness of research code: - Years ago, I was working on research code which simulated a power-grid. We needed to generate randomized load profiles. I noticed that each time it ran, we got the same results. As a software engineer, I figured I had to re-set the `random` seed, but that didn't work. I dug into the code, talked to the researcher, and found the load-profile algorithm: It was not randomly generated, but a hand-coded string of "1" and "0". - I later had the pleasure of adapting someone's research code. They had essentially hand-engineered IPC. It worked by calling a bash script from Python, which would open other Python processes and generate a random TCP/IP socket, the value of which was saved to an ENV variable. Assuming the socket was open, the Python scripts would then share the socket names of other filenames for the other processes to read and open. To prevent concurrency issues, sleep calls were used throughout the Python and Bash script. This was four Python scripts and two shell scripts, and to this day, I do not understand the reason this wasn't just one Python script.
- pennomi 3y agoAbsolutely my experience as well. Scientists write code that works, but is a pain to reproduce in any sort of scalable way. However it’s been getting better over time as programming is becoming a less niche skill.
- cauch 3y agoMy problem with this discussion is that a lot of people just say "I'm a scientist (or I'm working with scientists) and I'm observing X so I can say 'scientists blahblahblah'". Different scientific research fields are using widely different computer software environment, and have their own habits and traditions. The way a biologist uses programming has no reason to be similar to the way an astrophysicist does: they have not at all experienced the same software environment. It may even be useless to talk about "scientist" in the same field as two different labs working in the same field may have very different approaches (but it's more difficult if there are shared framework). So, I'm not at all surprised that you observe opposite experience. The same way I'm not surprised to see someone saying they had the opposite experience if someone says "European people are using a lot of 'g' and 'k' in their words" just because they observed what happened in Germany.
- smrtinsert 3y agoThe list of issues are mistakes juniors make, not best practices
- TrackerFF 3y agoOnly thing I've struggled with, is when real software engineers whip up "enterprise" code for even the simplest and most trivial programs. If you've heard of the infamous "enterprise hello world/fizzbuzz", then imagine that type of structure. I guess it stems from the ideology that it is better to do lots of groundwork now, in case the program blows up and needs to scale. Which is somewhat true...but in the world I work in, it is only true for maybe 1% of programs we write. So in the majority of cases, if I need to fork some software at work and do easy modifications, I do prefer the one-file programs, compared to some behemoth where almost everything is boilerplate, spread over multiple source files, folders, etc.
- senorrib 3y agoEvery year that passes these “SWE is an idiotic field” posts come earlier. So annoying…
- diracs_stache 3y agoNot sure what the exact context the blog refers to (they are a scientist turned software engineer?, their field is data/software intensive and see this as an improvement area?). Our team does engineering test and evaluation that include aspects of R&D and struggle with this. Scientists have academic approaches (must have sufficient sampling/statistical significance, sometimes delaying findings/reports checking additional aspects when a sanity check will suffice) but it does give rigor. On the software side, we definitely have spaghetti code, tools that rely on some file sitting in someone's H-drive, and plug-ins built by someone's old collaborator with little documentation. This is juxtaposed by the PM types that must be agile (fine when tasks are understood and defined enough to go nicely into a sprint, not always the case). Better communication on both sides would probably alleviate some of this but that is the great challenge in any group.
- mglz 3y agoI just handed in my PhD in computer science. Our department teaches "best practices" but adherence to them is hardly possible in research: 1) Requirements change constantly, since... it's research. We don't know where exactly we're going and what problems we encounter. 2) Buying faster hardware is usually an option. 3) Time spent on documentation, optimization or anything else that does not directly lead to results is directly detrimental to your progress. The published paper counts, nothing else. If a reviewer ask about reproducibility, just add a git repository link. 4) Most PhD students never worked in industry, and directly come from the Master's to the PhD. Hence there is no place where they'd encounter the need to create scalable systems. I guess Nr. 3 is has the worst impact. I would love to improve my project w.r.t. stability and reusability, but I would shoot myself into the foot: It's no publishable, I can't mention it a lot in my thesis, and the professorship doesn't check.
- alexmolas 3y ago> 3) Time spent on documentation, optimization or anything else that does not directly lead to results is directly detrimental to your progress. Here's is where I disagree. It's detrimental in the short term, but to ensure reproducibility and development speed in the future you need to follow best practices. Good science requires good engineering practices.
- jacobolus 3y agoThe point is, it's not prioritized since it's not rewarded. Grad students are incentivized to get their publications in and move on, not generate long-term stable engineering platforms for future generations.
- tesdinger 3y agoAn experimental research system does not have to be a complete practical system, it can focus on a few things to prove a point, support a scientific claim.
- 3y ago
- edu_guitar 3y agoOne notable difference between scientific code and regular software development is that the code scientists write is an implementation of well defined/documented mathematical models, while in a, say, web application, there is no reference paper or research, the code _is_ the reference. That's why best practices are important, not for the person writing a piece of software now, but for the future. If you need to change scientific code, papers and specification make otherwise confusing structure more manageable.
- davidd_1004 3y agoMost scientific code breaks when anyone but the author of the paper tries to run it
- alexeiz 3y agoA lot of scientific research code is execute-once-throw-away code. Once the code obtains a result you can put into your research paper, it has served its purpose and it'll never be used again. There is no need for any kind of abstraction, software design, architecture or development best practices. You're not going to be supporting this code or extending it in the future. If you're a software developer, the way researchers write code rubs you the wrong way. But you have to accept the reality. Applying software development principles to scientific code is just a waste of time.