3 ms·

It's not peer pressure - indeed, if anything, the people making noise are the ones espousing good coding practices. The problem is there's an intense selective

by Fomite 11y ago

It's not peer pressure - indeed, if anything, the people making noise are the ones espousing good coding practices. The problem is there's an intense selective pressure not to spend time on great code. There's a number of reasons for this - lots of code is only run once "for reals" or a small number of times. It's not necessarily going to be visible to the outside world. And there are other time pressures. To use two examples from my own work: 1. Right now, I'm working on some code that could really use improvement. It's hard coded to a specific project, when it could be generic. The variable names are a mess. It's run on a single thread, when it's practically begging to be parallelized. Doing all that, for me, will take some time. In the meantime, several things that will actually matter for my tenure portfolio someday are due. Things that will support my lab and it's projects, whereas this code...might come up again in a few months? And as I'm not writing ground-breaking software, "Authored X,Y,Z package..." is not going to be something a tenure committee even considers. Guess which one I'm going to work on? 2. I worked on some forecasting code for Ebola that I was actually proud of. Cleaned up a messy, ad-hoc, "And then I go in and change some variables based on what you put up in a Google Doc..." style system. Fully documented it. Made the variables arguments instead of being hard coded. Designed it so it could be used with minimal expertise. It was used for a week before the epidemic crested and forecasting stopped being of particular interest. There are papers I could have written instead.

AnimalMuppet 11y ago
> It was used for a week before the epidemic crested and forecasting stopped being of particular interest. There are papers I could have written instead. True. But if you had written the papers, and Ebola hadn't crested, you might now be saying, "There were lives I could have saved instead". Not knowing what the future was, you chose well.
- coliveira 11y ago
  You appear to imply that writing software could save lives while writing papers couldn't. However, for a researcher the balance frequently tilts the other way around. Software might be useful, but what people are expecting most of the time from a researcher is new research, which is conveyed by writing what he/she has discovered.
tikhonj 11y ago
I understand this perspective, and I've succumbed to the same sort of pressure in the past, but doesn't it feel like you actually end up losing net time in the long run by doing this? I mean, you save a bit of time up-front to hit a deadline but then you have to spent hours of frantic debugging when you should be sleeping to rerun a slightly modified benchmark for some other deadline. Or somebody suggests a good idea that you can't test quickly because the code is a mess. And then you either spend a bunch of extra time on it or pass on something that should have been easy because it wasn't. I only worked on a CS research project as an undergrad, but there we had the same dynamic. On the one hand, it made sense not to spend too much time writing good code, automating benchmarks... etc. On the other we spent too much time chasing down stupid bugs as the project went on. I wouldn't be surprised that, had we been slightly calmer and more methodical up front, we'd have saved time overall that month if not in the same week. And that's not counting how code like that makes research worse. Like, I see why writing a framework to optimize your benchmarks could be a waste of time, but it could also be the difference between running a bunch of tests to evaluate the project instead of just shoving the first ones we thought of into the paper because running more would take too much effort. It's not unique to research either: I ran into exactly the same sort of tradeoff working at an early stage startup. We care about putting out features above all until things came tumbling down. Spending a week or two chasing down bugs and making new features more expensive was bad, but then again we did need to test things and establish product/market fit quickly... My intuition is that this sort of pressure-based decisions end up a net loss of time even in the medium term, maybe even on the scale of weeks. But I don't know how to actually measure this sort of thing: we never measured how much time we spent on different tasks, and time is probably the wrong thing to measure anyhow. Debugging stupid code saps creative energy and lucidity even more than time, and how do I know what potential things didn't get done because the code was too ugly or, on the flip side, what things I could have had done in the time I spent making code better? How do you deal with this sort of trade-off? I'm not being rhetorical in the least, by the way: I genuinely don't know. But I really feel that incentives are geared towards short-term benefits in a way that is simply worse overall even across relatively short time horizons.
- BookmarkSaver 11y ago
  >It's not unique to research either: I ran into exactly the same sort of tradeoff working at an early stage startup. This is what you are missing. It is research. What they are saying is that the vast majority of the code academics write is "throwaway". It will only ever be used for a brief time or in a very limited capacity and then never again. This isn't software development. There is not technical debt incurred, because they almost never actually have to go back and run the code or repurpose it. There's not point in putting in the effort "up-front" for a deadline because there is no "later" that they usually have to deal with. This article is about the exceptions. And making sure to write cleanly factored, well documented, maintainable and flexible code every single time you need a program isn't worth it for the very rare instances when someone else actually needs to continue developing it.

by Fomite 11y ago

AnimalMuppet 11y ago

> It was used for a week before the epidemic crested and forecasting stopped being of particular interest. There are papers I could have written instead. True. But if you had written the papers, and Ebola hadn't crested, you might now be saying, "There were lives I could have saved instead". Not knowing what the future was, you chose well.

coliveira 11y ago
You appear to imply that writing software could save lives while writing papers couldn't. However, for a researcher the balance frequently tilts the other way around. Software might be useful, but what people are expecting most of the time from a researcher is new research, which is conveyed by writing what he/she has discovered.

tikhonj 11y ago

I understand this perspective, and I've succumbed to the same sort of pressure in the past, but doesn't it feel like you actually end up losing net time in the long run by doing this? I mean, you save a bit of time up-front to hit a deadline but then you have to spent hours of frantic debugging when you should be sleeping to rerun a slightly modified benchmark for some other deadline. Or somebody suggests a good idea that you can't test quickly because the code is a mess. And then you either spend a bunch of extra time on it or pass on something that should have been easy because it wasn't. I only worked on a CS research project as an undergrad, but there we had the same dynamic. On the one hand, it made sense not to spend too much time writing good code, automating benchmarks... etc. On the other we spent too much time chasing down stupid bugs as the project went on. I wouldn't be surprised that, had we been slightly calmer and more methodical up front, we'd have saved time overall that month if not in the same week. And that's not counting how code like that makes research worse. Like, I see why writing a framework to optimize your benchmarks could be a waste of time, but it could also be the difference between running a bunch of tests to evaluate the project instead of just shoving the first ones we thought of into the paper because running more would take too much effort. It's not unique to research either: I ran into exactly the same sort of tradeoff working at an early stage startup. We care about putting out features above all until things came tumbling down. Spending a week or two chasing down bugs and making new features more expensive was bad, but then again we did need to test things and establish product/market fit quickly... My intuition is that this sort of pressure-based decisions end up a net loss of time even in the medium term, maybe even on the scale of weeks. But I don't know how to actually measure this sort of thing: we never measured how much time we spent on different tasks, and time is probably the wrong thing to measure anyhow. Debugging stupid code saps creative energy and lucidity even more than time, and how do I know what potential things didn't get done because the code was too ugly or, on the flip side, what things I could have had done in the time I spent making code better? How do you deal with this sort of trade-off? I'm not being rhetorical in the least, by the way: I genuinely don't know. But I really feel that incentives are geared towards short-term benefits in a way that is simply worse overall even across relatively short time horizons.

BookmarkSaver 11y ago
>It's not unique to research either: I ran into exactly the same sort of tradeoff working at an early stage startup. This is what you are missing. It is research. What they are saying is that the vast majority of the code academics write is "throwaway". It will only ever be used for a brief time or in a very limited capacity and then never again. This isn't software development. There is not technical debt incurred, because they almost never actually have to go back and run the code or repurpose it. There's not point in putting in the effort "up-front" for a deadline because there is no "later" that they usually have to deal with. This article is about the exceptions. And making sure to write cleanly factored, well documented, maintainable and flexible code every single time you need a program isn't worth it for the very rare instances when someone else actually needs to continue developing it.