“developers are domain experts – they do not delegate programming tasks to programmers, which means they avoid the misunderstandings of the requirements common in many software projects”<p>This also likely means that these systems are poorly designed, poorly documented, poorly implemented, and poorly understood.<p>This is only my assumption based upon my reading of this article, but this assumption does come with some experience. I have worked in biotech my entire career, often alongside domain experts who write code. This code is typically, to be kind, not very good. It is rife with bugs, makes too many assumptions, is difficult to understand (and, as a consequence, its limitations and assumptions are not well understood by its users), full of copied code, etc. etc. etc. I have rewritten a few such systems.<p>Also, comments like the following are scary and I can only hope that they are not indicative of the general attitude in the field (though, based upon my own experience, may very well be):<p>"The software has huge societal importance, but the impact of software errors is very limited."<p>Yikes. The entire statement seems like a non-sequitur to me, but that attitude leads down a dangerous road. So we have potentially buggy systems which output data used in studies which have "huge societal impact"? How can the author make the claim that software errors don't have an appreciable impact on the result if the system was not developed using standard, accepted engineering practices? How do the users know how to correctly interpret the data?<p>As an analogy, I recently rewrote an imaging and image processing system used by my company. This system was designed and implemented by academics, and exhibits all of the problems we in the software industry typically associate with such code.<p>While rewriting it from scratch, I had no documentation to rely upon. I found many implicit and explicit assumptions that the users where not aware of. Most importantly, the system was originally designed for enumeration of certain types of cells, but not for any sort of quantitative interpretation.<p>However, down the road, the users in the lab realized that they raw output of the image analysis process could contain useful information. So, they started mining it. They began comparing samples using various measurements taken during analysis. They began making even more assumptions about what that data meant, but they were often wrong.<p>On the surface, it seemed as though their work made sense, but only if one did not understand <i>how</i> those numbers were gathered and <i>under what circumstances</i> their interpretation was valid. Some of the statements made by the author show a striking resemblance to the opinions of the original authors of the system I had to rewrite.<p>These people were smart, very smart, but not engineers. They didn't have the discipline, training, or experience required to write a system that would stand up to scrutiny. It was a research vehicle, and it did what it was originally intended to do, but as time passed, warts appeared.<p>I find it very hard to believe that climate model programming has even one single characteristic which would cause an engineer to think that a different engineering model was required or even warranted. To me this sounds like people in the research/academic camp making statements about an aspect of engineering that they do not understand.