Timeline for What do you do when code review is just too hard?
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 5, 2016 at 8:03 | comment | added | Adriano Repetti | @Matt Quality is a broad concept, however correctness is easier to define (it must be defined...), you may do not care (!) about overall code quality but you must care about its correctness. First because if your program crashes you waste time (and as you said in academia they constantly run out-of-time) and second because wrong code may cause disasters. What if your code to move telescope crashes and a proximity sensor fails? You damage your telescope crashing a wall. Bad thing. In some cases code may be raw and ugly but it must be correct (with, at least, two levels of tests)... | |
| Jul 4, 2016 at 12:52 | comment | added | Radu Murzea | I think a very important question here is: should the reviewer also test the code that he reviews ? This of course depends on the culture of the programming team and their rules. A "yes" answer to this question gives you a completely different solution than a "no" answer. | |
| Jul 3, 2016 at 18:19 | comment | added | Matt | @RubberDuck: Since this concept hasn't even reached most software companies, bashing academia for it makes little sense. In fact, you can thank academia (Floyd, Hoare, etc.) for the whole idea that you should be able to prove code is correct. Additionally, your comment only applies if the research result depends on the code being correct. For example, if an astronomer hacks up some horrible code for moving a telescope to their favorite nebula, it really doesn't matter if half the time it crashes on startup. It would be a waste of time to try to start proving things about the code. | |
| Jul 3, 2016 at 14:30 | comment | added | RubberDuck | @Matt if a researcher is going to use code as part of their research, then they should be able to prove it is correct. Unfortunately, this concept hasn't quite reached academia yet, which is (also) frankly astounding. | |
| Jul 1, 2016 at 20:47 | comment | added | Bill K | @LukeA.Leber I don't disagree with your point but as a counterpoint, the best jump I got in my career was when I stopped digging and insisted that a refactor needed to be done even though it would add a month to an already late project. I was the most junior dev on the project but when it shipped the customer insisted that it wouldn't deploy the app unless I came with it. SOMETIMES sanity and truthfulness is appreciated. | |
| Jul 1, 2016 at 17:23 | comment | added | Matt | @JonathanHartley: It is common in academia that a researcher (not really a programmer) tries to leverage some horrible code written by a previous, barely-contactable researcher (also not really a programmer). I have seen researchers who are programmers spend ages cleaning up such horrible code, but the code gets abandoned anyway when they leave, and their research never got finished because they spent too much time coding. I completely agree with you that learning how to produce quality code (I call that becoming a programmer) can allow you to avoid the whole problem in the first place. | |
| Jul 1, 2016 at 17:01 | comment | added | Matt | @EricLippert: I agree that the original question (and therefore your answer) is not about the scenario I describe. I was only responding to the later question of what might be different in an academic research case, but the instigating comment by tonysdg seems to have disappeared anyway. | |
| Jul 1, 2016 at 15:54 | comment | added | Jonathan Hartley | @Matt producing quality code does not take more time. This is a pervasive myth. Learning how to produce quality code takes some time and effort, but once you know how, it's actually faster to just do it right than to hack something together while continually dealing with the fallout. | |
| Jul 1, 2016 at 14:38 | comment | added | Eric Lippert | @Matt: The assumption of the question is that someone cares enough about code quality to have a formal system of code review in place, and that the person asking the question is concerned about the impact of large changes on the quality of the code. If we posit instead that no one cares about code quality then sure, my answer about ways to ensure code quality does not apply, but that's not the question that was asked! | |
| Jun 30, 2016 at 21:59 | comment | added | Matt | @EricLippert: I'm not trying to defend bad coding by any means, just to give a flavor of the difference between one very common (though of course not universal) academic scenario and the typical business scenario, in which (in contrast) we tacitly assume that code ought to be usable and maintainable by other people, and ought to be highly dependable. | |
| Jun 30, 2016 at 21:46 | comment | added | JS. | @LukeA.Leber You are correct. I've worked for these companies. What I can tell you is that death march will take years to complete, but every month will get progressively worse. The 'Code Monkeys' will be more miserable every month, but it will take years for the bad managers to realize the consequences of their actions... if ever. | |
| Jun 30, 2016 at 21:46 | comment | added | Matt | @EricLippert: Often, code used in academic research is not being used by anyone besides the current coder, so the main responsibility is to yourself. If your code crashes or gives weird answers half the time, and you can live with that, it's ok. Furthermore, many academic positions are time-limited, and when you're gone, your project stops being worked on -- it was not a group project. Producing quality code takes more time, but most academics are short on time and don't care as much about code quality or longevity (and often are not expert programmers anyway, nor was the original coder). | |
| Jun 30, 2016 at 20:16 | comment | added | Eric Lippert | @tonysdg: I don't think I said anything that was specific to line-of-business code. Why is it the case that these considerations do not apply to academic research? | |
| Jun 30, 2016 at 19:12 | comment | added | Owen | @JuliaHayward You are correct, but still, the situation Luke describes is common, especially on code that's already generating revenue. Really it's up to you whether it's worth it to keep working on it. | |
| Jun 30, 2016 at 9:08 | comment | added | Julia Hayward | @Luke if management or senior devs are so set on ploughing forwards despite the problems, and will even think about terminating anyone who tries to bring some sanity to this situation (OK, blatant insubordination aside), the company is on an irreversible death march. Leave them to it. | |
| Jun 30, 2016 at 0:59 | comment | added | Luke A. Leber | From what I've seen in the industry "Stopping Digging" is usually followed by swift termination which is followed by finding someone that is willing to use the shovel. This answer should add a disclaimer that lowly code-monkey peons shouldn't attempt this without being prepared for the consequences... | |
| Jun 28, 2016 at 22:40 | history | answered | Eric Lippert | CC BY-SA 3.0 |