Trusting Others to 'Do the Math'. Koeser, R. S. 40(4):376–392. ![Trusting Others to 'Do the Math' [link]](https://bibbase.org/img/filetypes/link.svg "link")
Paper doi abstract bibtex Researchers effectively trust the work of others anytime they use software tools or custom software. In this article I explore this notion of trusting others, using Digital Humanities as a focus, and drawing on my own experience. Software is inherently flawed and limited, so when its use in scholarship demands better practices and terminology, to review research software and describe development processes. It is also important to make research software engineers and their work more visible, both for the purposes of review and credit. [Excerpt] [...] Proposing additional work to that review process seems unrealistic and expensive, especially considering the additional knowledge and expertise that would be required. However, if we could implement some kind of code review alongside the other, more traditional scholarly outputs, it should help to make the role of software and software development more transparent in the work of scholarship. [...] If scholars must rely on others to 'do the math' of developing the software that is used in their work, then perhaps it is also logical that they should begin to rely on others to review and assess that portion of the scholarly work, and to check the accuracy and appropriateness of those hidden calculations. But this may be difficult to bring about. Software developers without a scholarly background may not be eager to get involved in the review and assessment process, and those who do may find it difficult to focus on the intellectual content and assumptions rather than software development best practices and implementation specifics. And demanding additional work of those few scholar-developers who do have the expertise would be an additional and undue burden. This is yet another reason why it is important work to advocate for research software engineers to be recognized and provided with a long-term career path that will keep them involved in scholarly work within academia. [] Software is ubiquitous, and ever more important to scholarship, but this fact is not always recognized or brought to the fore, particularly in humanities fields. Software is flawed, makes assumptions, and current algorithms may well be replaced by newer and better versions. We are constantly trusting others to 'do the math' at some point, but we would do well to make sure our trust is well-founded. Scholars should be more thoughtful about the software they use in their work, learn about its limitations, and think critically about the implications for their results. Both scholars and creators of software should take advantage of resources offered by groups like the Software Sustainability Institute and Software Carpentry and seek to extend their work to other disciplines. The people who develop software used for scholarly work and research are important to that work. The code and its authors should both be made more visible; we need to find ways for that technical work to be credited and cited, and reviewed along with the scholarship, so that our trust in those 'doing the math' is clear, explicit, and justified. [...]
@article{koeserTrustingOthersMath2015,
title = {Trusting Others to 'Do the Math'},
author = {Koeser, Rebecca S.},
date = {2015-10},
journaltitle = {Interdisciplinary Science Reviews},
volume = {40},
pages = {376--392},
issn = {1743-2790},
doi = {10.1080/03080188.2016.1165454},
url = {http://mfkp.org/INRMM/article/14218712},
abstract = {Researchers effectively trust the work of others anytime they use software tools or custom software. In this article I explore this notion of trusting others, using Digital Humanities as a focus, and drawing on my own experience. Software is inherently flawed and limited, so when its use in scholarship demands better practices and terminology, to review research software and describe development processes. It is also important to make research software engineers and their work more visible, both for the purposes of review and credit.
[Excerpt] [...] Proposing additional work to that review process seems unrealistic and expensive, especially considering the additional knowledge and expertise that would be required. However, if we could implement some kind of code review alongside the other, more traditional scholarly outputs, it should help to make the role of software and software development more transparent in the work of scholarship. [...] If scholars must rely on others to 'do the math' of developing the software that is used in their work, then perhaps it is also logical that they should begin to rely on others to review and assess that portion of the scholarly work, and to check the accuracy and appropriateness of those hidden calculations. But this may be difficult to bring about. Software developers without a scholarly background may not be eager to get involved in the review and assessment process, and those who do may find it difficult to focus on the intellectual content and assumptions rather than software development best practices and implementation specifics. And demanding additional work of those few scholar-developers who do have the expertise would be an additional and undue burden. This is yet another reason why it is important work to advocate for research software engineers to be recognized and provided with a long-term career path that will keep them involved in scholarly work within academia.
[] Software is ubiquitous, and ever more important to scholarship, but this fact is not always recognized or brought to the fore, particularly in humanities fields. Software is flawed, makes assumptions, and current algorithms may well be replaced by newer and better versions. We are constantly trusting others to 'do the math' at some point, but we would do well to make sure our trust is well-founded. Scholars should be more thoughtful about the software they use in their work, learn about its limitations, and think critically about the implications for their results. Both scholars and creators of software should take advantage of resources offered by groups like the Software Sustainability Institute and Software Carpentry and seek to extend their work to other disciplines. The people who develop software used for scholarly work and research are important to that work. The code and its authors should both be made more visible; we need to find ways for that technical work to be credited and cited, and reviewed along with the scholarship, so that our trust in those 'doing the math' is clear, explicit, and justified. [...]},
keywords = {*imported-from-citeulike-INRMM,~INRMM-MiD:c-14218712,~to-add-doi-URL,authorship,bias-correction,bias-disembodied-science-vs-computational-scholarship,computational-science,free-scientific-knowledge,peer-review,publication-bias,rewarding-best-research-practices},
number = {4}
}
Downloads: 0
{"_id":"fHjhWDDSANEcWE3oh","bibbaseid":"koeser-trustingotherstodothemath","authorIDs":[],"author_short":["Koeser, R. S."],"bibdata":{"bibtype":"article","type":"article","title":"Trusting Others to 'Do the Math'","author":[{"propositions":[],"lastnames":["Koeser"],"firstnames":["Rebecca","S."],"suffixes":[]}],"date":"2015-10","journaltitle":"Interdisciplinary Science Reviews","volume":"40","pages":"376–392","issn":"1743-2790","doi":"10.1080/03080188.2016.1165454","url":"http://mfkp.org/INRMM/article/14218712","abstract":"Researchers effectively trust the work of others anytime they use software tools or custom software. In this article I explore this notion of trusting others, using Digital Humanities as a focus, and drawing on my own experience. Software is inherently flawed and limited, so when its use in scholarship demands better practices and terminology, to review research software and describe development processes. It is also important to make research software engineers and their work more visible, both for the purposes of review and credit. [Excerpt] [...] Proposing additional work to that review process seems unrealistic and expensive, especially considering the additional knowledge and expertise that would be required. However, if we could implement some kind of code review alongside the other, more traditional scholarly outputs, it should help to make the role of software and software development more transparent in the work of scholarship. [...] If scholars must rely on others to 'do the math' of developing the software that is used in their work, then perhaps it is also logical that they should begin to rely on others to review and assess that portion of the scholarly work, and to check the accuracy and appropriateness of those hidden calculations. But this may be difficult to bring about. Software developers without a scholarly background may not be eager to get involved in the review and assessment process, and those who do may find it difficult to focus on the intellectual content and assumptions rather than software development best practices and implementation specifics. And demanding additional work of those few scholar-developers who do have the expertise would be an additional and undue burden. This is yet another reason why it is important work to advocate for research software engineers to be recognized and provided with a long-term career path that will keep them involved in scholarly work within academia. [] Software is ubiquitous, and ever more important to scholarship, but this fact is not always recognized or brought to the fore, particularly in humanities fields. Software is flawed, makes assumptions, and current algorithms may well be replaced by newer and better versions. We are constantly trusting others to 'do the math' at some point, but we would do well to make sure our trust is well-founded. Scholars should be more thoughtful about the software they use in their work, learn about its limitations, and think critically about the implications for their results. Both scholars and creators of software should take advantage of resources offered by groups like the Software Sustainability Institute and Software Carpentry and seek to extend their work to other disciplines. The people who develop software used for scholarly work and research are important to that work. The code and its authors should both be made more visible; we need to find ways for that technical work to be credited and cited, and reviewed along with the scholarship, so that our trust in those 'doing the math' is clear, explicit, and justified. [...]","keywords":"*imported-from-citeulike-INRMM,~INRMM-MiD:c-14218712,~to-add-doi-URL,authorship,bias-correction,bias-disembodied-science-vs-computational-scholarship,computational-science,free-scientific-knowledge,peer-review,publication-bias,rewarding-best-research-practices","number":"4","bibtex":"@article{koeserTrustingOthersMath2015,\n title = {Trusting Others to 'Do the Math'},\n author = {Koeser, Rebecca S.},\n date = {2015-10},\n journaltitle = {Interdisciplinary Science Reviews},\n volume = {40},\n pages = {376--392},\n issn = {1743-2790},\n doi = {10.1080/03080188.2016.1165454},\n url = {http://mfkp.org/INRMM/article/14218712},\n abstract = {Researchers effectively trust the work of others anytime they use software tools or custom software. In this article I explore this notion of trusting others, using Digital Humanities as a focus, and drawing on my own experience. Software is inherently flawed and limited, so when its use in scholarship demands better practices and terminology, to review research software and describe development processes. It is also important to make research software engineers and their work more visible, both for the purposes of review and credit.\n\n[Excerpt] [...] Proposing additional work to that review process seems unrealistic and expensive, especially considering the additional knowledge and expertise that would be required. However, if we could implement some kind of code review alongside the other, more traditional scholarly outputs, it should help to make the role of software and software development more transparent in the work of scholarship. [...] If scholars must rely on others to 'do the math' of developing the software that is used in their work, then perhaps it is also logical that they should begin to rely on others to review and assess that portion of the scholarly work, and to check the accuracy and appropriateness of those hidden calculations. But this may be difficult to bring about. Software developers without a scholarly background may not be eager to get involved in the review and assessment process, and those who do may find it difficult to focus on the intellectual content and assumptions rather than software development best practices and implementation specifics. And demanding additional work of those few scholar-developers who do have the expertise would be an additional and undue burden. This is yet another reason why it is important work to advocate for research software engineers to be recognized and provided with a long-term career path that will keep them involved in scholarly work within academia.\n\n[] Software is ubiquitous, and ever more important to scholarship, but this fact is not always recognized or brought to the fore, particularly in humanities fields. Software is flawed, makes assumptions, and current algorithms may well be replaced by newer and better versions. We are constantly trusting others to 'do the math' at some point, but we would do well to make sure our trust is well-founded. Scholars should be more thoughtful about the software they use in their work, learn about its limitations, and think critically about the implications for their results. Both scholars and creators of software should take advantage of resources offered by groups like the Software Sustainability Institute and Software Carpentry and seek to extend their work to other disciplines. The people who develop software used for scholarly work and research are important to that work. The code and its authors should both be made more visible; we need to find ways for that technical work to be credited and cited, and reviewed along with the scholarship, so that our trust in those 'doing the math' is clear, explicit, and justified. [...]},\n keywords = {*imported-from-citeulike-INRMM,~INRMM-MiD:c-14218712,~to-add-doi-URL,authorship,bias-correction,bias-disembodied-science-vs-computational-scholarship,computational-science,free-scientific-knowledge,peer-review,publication-bias,rewarding-best-research-practices},\n number = {4}\n}\n\n","author_short":["Koeser, R. S."],"key":"koeserTrustingOthersMath2015","id":"koeserTrustingOthersMath2015","bibbaseid":"koeser-trustingotherstodothemath","role":"author","urls":{"Paper":"http://mfkp.org/INRMM/article/14218712"},"keyword":["*imported-from-citeulike-INRMM","~INRMM-MiD:c-14218712","~to-add-doi-URL","authorship","bias-correction","bias-disembodied-science-vs-computational-scholarship","computational-science","free-scientific-knowledge","peer-review","publication-bias","rewarding-best-research-practices"],"downloads":0},"bibtype":"article","biburl":"https://tmpfiles.org/dl/58794/INRMM.bib","creationDate":"2020-07-02T22:41:11.315Z","downloads":0,"keywords":["*imported-from-citeulike-inrmm","~inrmm-mid:c-14218712","~to-add-doi-url","authorship","bias-correction","bias-disembodied-science-vs-computational-scholarship","computational-science","free-scientific-knowledge","peer-review","publication-bias","rewarding-best-research-practices"],"search_terms":["trusting","others","math","koeser"],"title":"Trusting Others to 'Do the Math'","year":null,"dataSources":["DXuKbcZTirdigFKPF"]}