4 ms·

Once I did some science. And the reason for my bad quality code is (or I hope that it was) that I used to: 1. write the code 2. get some result 3. forget it. t

Once I did some science. And the reason for my bad quality code is (or I hope that it was) that I used to: 1. write the code 2. get some result 3. forget it. throw it away And I have never felt any pain for maintaining that code. Until I started developing software for some business. Now the whole team has to work on the same codebase forever improving it with new features. It is totally different workflow compared to my science doing in the past.

Ntrails 9y ago
The other part of not reusing code is that you tend to be pretty casual about edge cases/testing. If I know the params will be valid and the data set well formed (I made them) then I don't need to write 100 lines of checking. My test is two simple test runs, did they give me the answer I expected? Yes! Winner. Set off long running job and go home
- rmonroe 9y ago
  This is precisely the difference from regular programming: Our code is typically going to be used by a very small number of people, and the inputs are typically very well constrained. It's typically faster to just call up the new prospective user and explain the code than to triple your development time making it rock solid. For instance, I'm currently working on a project where I have to process 110 GB/s of radio data aggregated from 288 antennas. The data will need intensive cleaning after, so plenty of thought is put into logging the right statistics (since we have to average for 3 months to get the right data). This is where the real effort is being applied. However, if there happens to be a missing edge case or malformed data packet, I can (and will) just cronjob a (if process hung, pkill and restart) the processor with the next bit of realtime data. Anyone who wants to reuse the algorithm will need our exact same antennas and specialized computing hardware, so why make it portable?
  - astrobe_ 9y ago
    Portable, certainly not. Verifiable and replicable, certainly yes. Otherwise that's not the work of scientist. Programs are mathematical proofs. If the mathematical proofs are a weak link in a scientific work, then this is a serious problem.

Ntrails 9y ago

The other part of not reusing code is that you tend to be pretty casual about edge cases/testing. If I know the params will be valid and the data set well formed (I made them) then I don't need to write 100 lines of checking. My test is two simple test runs, did they give me the answer I expected? Yes! Winner. Set off long running job and go home

rmonroe 9y ago
This is precisely the difference from regular programming: Our code is typically going to be used by a very small number of people, and the inputs are typically very well constrained. It's typically faster to just call up the new prospective user and explain the code than to triple your development time making it rock solid. For instance, I'm currently working on a project where I have to process 110 GB/s of radio data aggregated from 288 antennas. The data will need intensive cleaning after, so plenty of thought is put into logging the right statistics (since we have to average for 3 months to get the right data). This is where the real effort is being applied. However, if there happens to be a missing edge case or malformed data packet, I can (and will) just cronjob a (if process hung, pkill and restart) the processor with the next bit of realtime data. Anyone who wants to reuse the algorithm will need our exact same antennas and specialized computing hardware, so why make it portable?
- astrobe_ 9y ago
  Portable, certainly not. Verifiable and replicable, certainly yes. Otherwise that's not the work of scientist. Programs are mathematical proofs. If the mathematical proofs are a weak link in a scientific work, then this is a serious problem.