A big part of the problem is that current researchers did have to manage their programming, IT, etc. during undergrad, grad, and post-doc periods. They did a lot of hacking with C, Perl, and Maple/MATLAB/etc.

As with many managers who were promoted because they were stellar engineers, those skills fade but they continue to think that they are qualified to judge the difficulty of the work. The fact that they have "done it"[1] before leads to a logically incorrect assumption that it's not that difficult.

After all, they learned those things on their own while thinking about the tough stuff.

[1] Except for, of course, in a predictable, repeatable, safe, auditable, etc. way with fifty other users asking for high priority changes.

I know many academics who spent a lot of time throughout their school career writing code to get their research done.

They looked at this as a necessary evil, and as such learned the bare amount minimum to get by. They are smart people and were able to make the code help them solve their research problem. But they are busy thinking about their research so usually their algorithms are fairly simple + straightforward (lots of nested loops and n^2 sort of things).

The main problem, in my experience, is that many of the research problems are actually fairly simple (algorithmically) and most research departments have access to fairly powerful computing facilities. Coupled, this means you can brute force a lot of solutions-- there is no real push for understanding of the algorithmic complexity.

As well, most academics are on a much MUCH longer timeline than your average business or startup. Did your algorithm break 1 month into processing your simulation? Fine, fix it and run it for another month. Or just take what you had and publish it anyways.

Just as academics look down upon the technical side of things, we are just as much to blame for idolizing the academics. Science (even in math and engineering) is a lot more 'sloppy' then we like to imagine. There are oodles of papers out there that are just downright incorrect-- and not on purpose!

(* My creds: I have participated in academia as both a student, researcher and software developer )

There's a huge resistance to using source control, so lots of time gets spent searching through deep folder structures and finding just which 'file1_v3 (4).doc' is the right one. Data gets lost due to simple mistakes.

They spent 20 minutes coding the Runge-Kutta algorithm every time they need to run a numerical simulation without realizing or caring that (a) they could spend 25 minutes to create a function that they could reuse or (b) that the function already exists.

In short, the issue isn't computing time, it's researcher time. But the idea of spending some time now to save time later is so foreign because of the focus on getting the publication out as quick as possible.

In industry, what I've seen is that often engineers are scrambling to please managers or customers, with work divided among multiple people, so the code is usually poorly written and undocumented.

In academics, publications are of primary importance, so everything is documented. The longer timescale means there's more time to refine code that's designed for a single, focused problem. The limited scope of the programs used means code quality isn't an issue most of the time.

Also, in theoretical computer science at least, the focus is entirely on rigorous proofs and finding optimal algorithms. While in industry, it's more "get practical things done quickly so we can sell it".

That's a pretty short sighted example of industry - I'm sure those examples are out there, but I don't think they're common (or the companies long lived).

Most places I've worked know that they'll have to maintain that code well into the future.

Not really so in academia (publish and forget) - which is why it's rare to see even basic measures taken for modularity and abstraction, e.g. the creation of types to represent entities in the problem domain. I think I've seen that done in Matlab, once.