> I once had to untangle a hairball of stuff made by someone with enough titles that his last name tended to fall off the line or be clipped.
In my experience, the problem rather is that in science, the intention of the code is to be able to run well enough such that one or two papers can be made out of it and after that, it may be forgotten.
For this purpose, this kind of coding is actually decent and (unluckily) investing time in good software engineering practises would mean that you have less time for writing papers.
In this sense, I would be cautious to call this kind of code "bad", but rather say that if you write code for a company, the priorities are very different.
That code was old rather than bad. And I had the distinct feeling that whoever wrote it simply did not have a lot of background in software and had a job to be done no matter how it got done. And then that code started a life of its own because the software did work most of the time. Edge cases (sometimes literally edge cases: edges of networks of steel trusses) would sometimes give the weirdest results and upon closer inspection you'd find lots of errors in the rest of the output, just not large enough to immediately cause suspicion.
In the end it all worked out and it was a very good lesson in trying to keep the output stable while refactoring the code. This was well before 'TDD'.
In my experience, the problem rather is that in science, the intention of the code is to be able to run well enough such that one or two papers can be made out of it and after that, it may be forgotten.
For this purpose, this kind of coding is actually decent and (unluckily) investing time in good software engineering practises would mean that you have less time for writing papers.
In this sense, I would be cautious to call this kind of code "bad", but rather say that if you write code for a company, the priorities are very different.