5 ms·

Hi, I'm a bioinformatics researcher. Apparently I work for this guy's ex(?)-employer although I have never heard of him before. My single most limited resource

Hi, I'm a bioinformatics researcher. Apparently I work for this guy's ex(?)-employer although I have never heard of him before. My single most limited resource is programmer time. My time and the time of other people who work with me. I have access to loads of computers that sit idle all the time, even if it is on nights and weekends. There is zero opportunity cost to me in using these computers more fully. I have enough human work to do that I can wait for the results without having any wait states. There can be a big opportunity cost in trying to rework a workflow so that it is more efficient and then test it thoroughly ensure correctness. Doing this may seem more appealing to someone who is interested primarily in computational efficiency. But I am more interested in research efficiency, and so are my employers and funders.

hnwh 14y ago
How can you leverage all of us really good programmers with tons of time, who are dying to work on something "important" and meaningful?
- michaelhoffman 14y ago
  If you want to improve the software engineering quality of bioinformatics software, then find an open source project you are interested in, and offer to submit patches to improve really unsexy but important stuff for bioinformatics user experience. Things like documentation, deployment, user interface, and testing. Some of these things require little domain knowledge but no one wants to do them. Edited to add: some projects might even have a bug tracker that will already have problems you can tackle.
  - artmageddon 14y ago
    Got any examples?
    - michaelhoffman 14y ago
      See other response above: https://news.ycombinator.com/item?id=5124490 https://news.ycombinator.com/item?id=5124490
      - artmageddon 14y ago
        Thank you!!
  - kolinko 14y ago
    Where to start? Any list of this projects? I don't do programming for fun, but I'll be visiting a local university soon, and could share this with students.
    - michaelhoffman 14y ago
      Our Genomedata[1] storage format/API should be readily comprehensible, and has a Google Code tracker: [1] http://noble.gs.washington.edu/proj/genomedata/ http://noble.gs.washington.edu/proj/genomedata/ [2] http://code.google.com/p/genomedata/issues/list http://code.google.com/p/genomedata/issues/list
east2west 14y ago
Well, I can call myself a bioinformatics researcher, I guess, as I have CS Ph.D working in genetics/genomics. I see your point of throwing computers at simple solutions as cheaper than throwing good programmers. I do that too. We are very fortunate in that we write run-once programs that only have to work in one environment using one inputs. However, bad programmers write incorrect programs, which give wrong conclusions that lead to faulty clinical trials (look up Duke University facing class-action law-suit). I have seen people parsing Gigabytes-files with one line of Awk. People seem to forget that good engineering practice is learned with blood. Is it any wonder academic research is looked with suspicion by the pharmaceutical companies?
- aheilbut 14y ago
  The Duke situation to which you refer was fraud, not just a result of programmer error or poor engineering practice.
  - east2west 14y ago
    It was initially a programming error but the Duke researchers refused to acknowledge it and reanalyze their data, because that might mean retracting their prominent paper. From there it just snowballed. It was certainly fraud after the error was pointed out to them. There might also be other elements of fraud in their paper. I watched a presentation by MD. Anderson researchers who spotted the error and spent more than two years trying to call attention to it.
    - aheilbut 14y ago
      The smoking gun was an error, but there were something like 9 Potti papers that ended up getting retracted. There's no way that someone could have accidentally made that many mistakes...
      - chris_wot 14y ago
        Why is that?
epistasis 14y ago
>There can be a big opportunity cost in trying to rework a workflow so that it is more efficient and then test it thoroughly ensure correctness. Hi, I recognize your name as a legit bioinformatician, am a huge fan of the lab that you're currently in, and others should listen to you. I'd like to add that for many projects, general reusable software engineering is not necessarily a huge advantage. Instead of verifying a single implementation, it's often better for somebody to reimplement the idea from scratch; if a second implementation in a different language written by a different programmer gets the same results, this is a much more thorough validation of the software than going over prototype software line by line. Also, I've seen way too many software engineers come in with an enterprisey attitude of establishing all sorts of crazy infrastructure and get absolutely no work done. If Java is your idea of a good time, it's unlikely that you'll be an effective researcher (though it's not unheard of), because it's not good at maximizing single-programmer output, and not good at maximizing I/O or CPU or string processing. In research it's best to get results, fail fast fast fast, and move on to the next idea. If you're lucky, 1 in 20 will work out. Publish your crap, and if it's a good idea, it will be worth polishing the turd later, but it's better to explore the field then to spend too much time on an uninteresting area. The only time you worry about efficiency is when it enables a whole other level of analysis. So, for example, UCSC does most of their work in C, including an entire web app and framework written in C, because when they were doing the draft assembly of human genome a decade ago on a small cluster of computers that they scrounged from secretaris' desks over the summer, Perl wouldn't cut it.
- kanzure 14y ago
  > and if it's a good idea, it will be worth polishing the turd later, Which of the released turds do you consider to be polished?
  - epistasis 14y ago
    Pretty much anything that gets used by many people ends up getting polished (the exception being the RNA-seq field, it's still pretty rough out there, but the research is still taking quite a while). And if you're writing software, your tool isn't going to get used until it's somewhat polished, or is so unique and essential in its purpose that people have to use it. In terms of next-generation sequence analysis, Heng Li's BWA mapper and Samtools libraries are fairly good. His coding style is a bit terse for my tastes, but it keeps out people who don't know what they're doing, it's very clear code for semi-complicated algorithms, and BWA is some of the most reliable software I use everyday. On the infrastructure side, Galaxy [https://main.g2.bx.psu.edu https://main.g2.bx.psu.edu] is getting fairly good. The BioConductor repository of R packages is extremely mixed. I don't like some of their architectural choices, but it's ended up working out OK. I still use Michael Eisen's Cluster from a decade ago, along with Java TreeView.

hnwh 14y ago

How can you leverage all of us really good programmers with tons of time, who are dying to work on something "important" and meaningful?

michaelhoffman 14y ago
If you want to improve the software engineering quality of bioinformatics software, then find an open source project you are interested in, and offer to submit patches to improve really unsexy but important stuff for bioinformatics user experience. Things like documentation, deployment, user interface, and testing. Some of these things require little domain knowledge but no one wants to do them. Edited to add: some projects might even have a bug tracker that will already have problems you can tackle.
- artmageddon 14y ago
  Got any examples?
  - michaelhoffman 14y ago
    See other response above: https://news.ycombinator.com/item?id=5124490 https://news.ycombinator.com/item?id=5124490
    - artmageddon 14y ago
      Thank you!!
- kolinko 14y ago
  Where to start? Any list of this projects? I don't do programming for fun, but I'll be visiting a local university soon, and could share this with students.
  - michaelhoffman 14y ago
    Our Genomedata[1] storage format/API should be readily comprehensible, and has a Google Code tracker: [1] http://noble.gs.washington.edu/proj/genomedata/ http://noble.gs.washington.edu/proj/genomedata/ [2] http://code.google.com/p/genomedata/issues/list http://code.google.com/p/genomedata/issues/list

east2west 14y ago

Well, I can call myself a bioinformatics researcher, I guess, as I have CS Ph.D working in genetics/genomics. I see your point of throwing computers at simple solutions as cheaper than throwing good programmers. I do that too. We are very fortunate in that we write run-once programs that only have to work in one environment using one inputs. However, bad programmers write incorrect programs, which give wrong conclusions that lead to faulty clinical trials (look up Duke University facing class-action law-suit). I have seen people parsing Gigabytes-files with one line of Awk. People seem to forget that good engineering practice is learned with blood. Is it any wonder academic research is looked with suspicion by the pharmaceutical companies?

aheilbut 14y ago
The Duke situation to which you refer was fraud, not just a result of programmer error or poor engineering practice.
- east2west 14y ago
  It was initially a programming error but the Duke researchers refused to acknowledge it and reanalyze their data, because that might mean retracting their prominent paper. From there it just snowballed. It was certainly fraud after the error was pointed out to them. There might also be other elements of fraud in their paper. I watched a presentation by MD. Anderson researchers who spotted the error and spent more than two years trying to call attention to it.
  - aheilbut 14y ago
    The smoking gun was an error, but there were something like 9 Potti papers that ended up getting retracted. There's no way that someone could have accidentally made that many mistakes...
    - chris_wot 14y ago
      Why is that?

epistasis 14y ago

>There can be a big opportunity cost in trying to rework a workflow so that it is more efficient and then test it thoroughly ensure correctness. Hi, I recognize your name as a legit bioinformatician, am a huge fan of the lab that you're currently in, and others should listen to you. I'd like to add that for many projects, general reusable software engineering is not necessarily a huge advantage. Instead of verifying a single implementation, it's often better for somebody to reimplement the idea from scratch; if a second implementation in a different language written by a different programmer gets the same results, this is a much more thorough validation of the software than going over prototype software line by line. Also, I've seen way too many software engineers come in with an enterprisey attitude of establishing all sorts of crazy infrastructure and get absolutely no work done. If Java is your idea of a good time, it's unlikely that you'll be an effective researcher (though it's not unheard of), because it's not good at maximizing single-programmer output, and not good at maximizing I/O or CPU or string processing. In research it's best to get results, fail fast fast fast, and move on to the next idea. If you're lucky, 1 in 20 will work out. Publish your crap, and if it's a good idea, it will be worth polishing the turd later, but it's better to explore the field then to spend too much time on an uninteresting area. The only time you worry about efficiency is when it enables a whole other level of analysis. So, for example, UCSC does most of their work in C, including an entire web app and framework written in C, because when they were doing the draft assembly of human genome a decade ago on a small cluster of computers that they scrounged from secretaris' desks over the summer, Perl wouldn't cut it.

kanzure 14y ago
> and if it's a good idea, it will be worth polishing the turd later, Which of the released turds do you consider to be polished?
- epistasis 14y ago
  Pretty much anything that gets used by many people ends up getting polished (the exception being the RNA-seq field, it's still pretty rough out there, but the research is still taking quite a while). And if you're writing software, your tool isn't going to get used until it's somewhat polished, or is so unique and essential in its purpose that people have to use it. In terms of next-generation sequence analysis, Heng Li's BWA mapper and Samtools libraries are fairly good. His coding style is a bit terse for my tastes, but it keeps out people who don't know what they're doing, it's very clear code for semi-complicated algorithms, and BWA is some of the most reliable software I use everyday. On the infrastructure side, Galaxy [https://main.g2.bx.psu.edu https://main.g2.bx.psu.edu] is getting fairly good. The BioConductor repository of R packages is extremely mixed. I don't like some of their architectural choices, but it's ended up working out OK. I still use Michael Eisen's Cluster from a decade ago, along with Java TreeView.