4 ms·

In my workplace code review were done mostly during debug sessions, when people ask their peers for helping. If code went through smoothly, then no code review

by methou 11y ago

In my workplace code review were done mostly during debug sessions, when people ask their peers for helping. If code went through smoothly, then no code review were done. In this specific case, I believe well written tests/good coverage would be more prioritized than code review. Besides, most codes we wrote are merely prototypes that won't be used again.

maxxxxx 11y ago
"Besides, most codes we wrote are merely prototypes that won't be used again." I used to work with scientists that said pretty much the same thing. Once their stuff started working we had to deal with a huge pile of very badly written code and make this into a product quickly.
- danieltillett 11y ago
  As a scientist who writes code, a good 95% of all the code I write is prototype code that gets written just to see if an approach will work. Almost everything I write never gets used again because the idea failed. This is just the nature of research. I do make an effort to rewrite what I have hacked together once I have a working approach, but if I wrote everything correctly from the start I would be wasting a huge amount of time and get very little actually done.
  - analog31 11y ago
    I'm a scientist too. A lot of my code is not even what I would call a prototype. Many of my programs get used exactly once, by myself. I write a program to solve a specific problem, and when the problem is solved, I move on to something else. Now, I also do some prototyping, but my workplace has a formal software development process, and my code would never leak into a product. For one thing, I use a different language than the programming department. Likewise for the electronics and embedded portions of my prototypes. Sometimes my code continues to serve a useful purpose, for instance allowing testing of the hardware portions of a product, months before production software is ready to use. And if our codes produce different results, well, let's just say that I've lost a few bets, but have also won a few. ;-) With all those things said, I'd welcome review of my code in any "critical" situation, including preparation of results for publication.
    - danieltillett 11y ago
      I think the problem is expecting that there is a one-size-fits-all approach to writing software. I have had many discussions with developers over the years who come from a pure CS background who really disparage the code scientists write. Yes a lot of the code is not good code, but it would not have been possible to get anything done at all if strict coding standards had been applied from the start. The best approach I think is to take a hybrid approach of hack and then rewrite. I have worked on problems where I have written 10,000s of lines of very hacky code over many months and once I had a viable solution rewrote the whole module from scratch in a week. The key is to make sure you (or someone else) re-writes the code once it is working if you are going to use again and not pretend that what you have hacked together is acceptable just because it (sometimes) works.
      - collyw 11y ago
        As a software engineer (who works with scientists) that pretty much how I write new bits of code where I am unsure if the approach will work. Try a quick hacky version, and if that appers to be working, rewite it "properly". If its going to be complex, then start off writing it reasonably well in the first place as it will make debugging much easier.
        danieltillett 11y ago
        You raise a good point about debugging - I have had to rewrite some hacky code just because it just became too complex to debug efficiently long before it was ready to be rewritten for final use.
      - analog31 11y ago
        Call it "refactoring" and you're golden. ;-) For me, it's less about standards than about tools. I don't think software development is slow because of standards. I don't use the same tool chain as the developers, so I'm oblivious to their standards. Their code is unreadable to me. I follow what would probably have been considered good practices 15 years ago when programs tended to be smaller. I actually learned good hygiene, but in the context of BASIC and Pascal in the 1980s, not the massive tool chains of today. And my programs probably look like a throwback to that era in terms of their conceptual structure. I re-write early and often. Transforming a program is a good way to find out if it made sense in the first place.
  - pjtr 11y ago
    This reminds me of a recent popular quote: "The only difference between screwing around and science is writing it down." Can we comapre "Screwing around" to "Hacked together" (undocumented?) throw-away code and "Writing it down" to "Correctly written" (documented?) code? Aren't you as a scientist supposed to also document what ideas failed? Now it depends a bit on what you mean exactly by "hacked together" and "correctly written" I guess. I'm all for prototyping and getting to the "heart" of a problem quickly to confirm / reject ideas. But I wonder. Do e.g. chemists feel they could try more experiments quicker if they didn't have to take notes on what they tried and what happened? Is there a comparable activity to hacking together throw-away code in chemistry (or other older fields of science)?
    - danieltillett 11y ago
      It is not a matter of not taking notes (code is notes), it is more a case of not writing code that handles all the edge cases, writing good comments, and most importantly taking the time to design the software and api's well. All of this is worth doing, but it takes a lot more time than just hacking together some code to test if an idea will work. To answer your other question in science yes there is the equivalent of hacking something together just to see if the idea will work. It is very common to do a quick experiment to see if something will work before going back and doing all the controls and working out how robust the experimental conditions are. Science is hard and almost everything you do fails.
  - maxxxxx 11y ago
    I am not advocating for doing everything perfectly from the start but I think scientists who write code should at least try to learn some basic software engineering skills. I am talking about simple things like writing a function instead of copy/paste the same 500 lines of code 10 times, using STL containers instead of heap allocated arrays everywhere, meaningful variable names or (my favorite) using variables for important numbers instead of putting the number 8 everywhere into the code so you don't know if 7 is "8-1" or really is just 7. Some of the scientists I worked with somehow took pride in not following any coding practices because they were scientists, not mere coders. I believe in this particular startup I worked for these practices contributed to the eventual failure since we had 100s of thousands of lines of prototype code that crashed left and right and nobody knew exactly what it's doing because there was almost no documentation. I think a little respect for engineering practices is a good thing for scientists and I don't think it impedes their creativity.
    - danieltillett 11y ago
      A lot of scientists are ether self taught coders, or taught by other self taught scientists and so are ignorant of bad practices to avoid. Developers with experience should be helping educate the scientists in a positive way that the scientists don't feel like they are considered idiots by the developers. Respect is the key. The problem with the startup you describe sounds more like a management problem. Hacked code that sometimes works is not code that should be used more than once and it should be rewritten before check in. If the scientists don't know how to do this then they need to be helped.

by methou 11y ago

maxxxxx 11y ago

"Besides, most codes we wrote are merely prototypes that won't be used again." I used to work with scientists that said pretty much the same thing. Once their stuff started working we had to deal with a huge pile of very badly written code and make this into a product quickly.

danieltillett 11y ago
As a scientist who writes code, a good 95% of all the code I write is prototype code that gets written just to see if an approach will work. Almost everything I write never gets used again because the idea failed. This is just the nature of research. I do make an effort to rewrite what I have hacked together once I have a working approach, but if I wrote everything correctly from the start I would be wasting a huge amount of time and get very little actually done.
- analog31 11y ago
  I'm a scientist too. A lot of my code is not even what I would call a prototype. Many of my programs get used exactly once, by myself. I write a program to solve a specific problem, and when the problem is solved, I move on to something else. Now, I also do some prototyping, but my workplace has a formal software development process, and my code would never leak into a product. For one thing, I use a different language than the programming department. Likewise for the electronics and embedded portions of my prototypes. Sometimes my code continues to serve a useful purpose, for instance allowing testing of the hardware portions of a product, months before production software is ready to use. And if our codes produce different results, well, let's just say that I've lost a few bets, but have also won a few. ;-) With all those things said, I'd welcome review of my code in any "critical" situation, including preparation of results for publication.
  - danieltillett 11y ago
    I think the problem is expecting that there is a one-size-fits-all approach to writing software. I have had many discussions with developers over the years who come from a pure CS background who really disparage the code scientists write. Yes a lot of the code is not good code, but it would not have been possible to get anything done at all if strict coding standards had been applied from the start. The best approach I think is to take a hybrid approach of hack and then rewrite. I have worked on problems where I have written 10,000s of lines of very hacky code over many months and once I had a viable solution rewrote the whole module from scratch in a week. The key is to make sure you (or someone else) re-writes the code once it is working if you are going to use again and not pretend that what you have hacked together is acceptable just because it (sometimes) works.
    - collyw 11y ago
      As a software engineer (who works with scientists) that pretty much how I write new bits of code where I am unsure if the approach will work. Try a quick hacky version, and if that appers to be working, rewite it "properly". If its going to be complex, then start off writing it reasonably well in the first place as it will make debugging much easier.
      - danieltillett 11y ago
        You raise a good point about debugging - I have had to rewrite some hacky code just because it just became too complex to debug efficiently long before it was ready to be rewritten for final use.
    - analog31 11y ago
      Call it "refactoring" and you're golden. ;-) For me, it's less about standards than about tools. I don't think software development is slow because of standards. I don't use the same tool chain as the developers, so I'm oblivious to their standards. Their code is unreadable to me. I follow what would probably have been considered good practices 15 years ago when programs tended to be smaller. I actually learned good hygiene, but in the context of BASIC and Pascal in the 1980s, not the massive tool chains of today. And my programs probably look like a throwback to that era in terms of their conceptual structure. I re-write early and often. Transforming a program is a good way to find out if it made sense in the first place.
- pjtr 11y ago
  This reminds me of a recent popular quote: "The only difference between screwing around and science is writing it down." Can we comapre "Screwing around" to "Hacked together" (undocumented?) throw-away code and "Writing it down" to "Correctly written" (documented?) code? Aren't you as a scientist supposed to also document what ideas failed? Now it depends a bit on what you mean exactly by "hacked together" and "correctly written" I guess. I'm all for prototyping and getting to the "heart" of a problem quickly to confirm / reject ideas. But I wonder. Do e.g. chemists feel they could try more experiments quicker if they didn't have to take notes on what they tried and what happened? Is there a comparable activity to hacking together throw-away code in chemistry (or other older fields of science)?
  - danieltillett 11y ago
    It is not a matter of not taking notes (code is notes), it is more a case of not writing code that handles all the edge cases, writing good comments, and most importantly taking the time to design the software and api's well. All of this is worth doing, but it takes a lot more time than just hacking together some code to test if an idea will work. To answer your other question in science yes there is the equivalent of hacking something together just to see if the idea will work. It is very common to do a quick experiment to see if something will work before going back and doing all the controls and working out how robust the experimental conditions are. Science is hard and almost everything you do fails.
- maxxxxx 11y ago
  I am not advocating for doing everything perfectly from the start but I think scientists who write code should at least try to learn some basic software engineering skills. I am talking about simple things like writing a function instead of copy/paste the same 500 lines of code 10 times, using STL containers instead of heap allocated arrays everywhere, meaningful variable names or (my favorite) using variables for important numbers instead of putting the number 8 everywhere into the code so you don't know if 7 is "8-1" or really is just 7. Some of the scientists I worked with somehow took pride in not following any coding practices because they were scientists, not mere coders. I believe in this particular startup I worked for these practices contributed to the eventual failure since we had 100s of thousands of lines of prototype code that crashed left and right and nobody knew exactly what it's doing because there was almost no documentation. I think a little respect for engineering practices is a good thing for scientists and I don't think it impedes their creativity.
  - danieltillett 11y ago
    A lot of scientists are ether self taught coders, or taught by other self taught scientists and so are ignorant of bad practices to avoid. Developers with experience should be helping educate the scientists in a positive way that the scientists don't feel like they are considered idiots by the developers. Respect is the key. The problem with the startup you describe sounds more like a management problem. Hacked code that sometimes works is not code that should be used more than once and it should be rewritten before check in. If the scientists don't know how to do this then they need to be helped.