3 ms·

"Quality? But how does that affect our bottom line?" :)

by VOYD 10y ago

dandelany 10y ago
I know you're joking... But it really does affect the bottom line! I've learned the hard way that taking twice as long to do something the right way will be more economical in the long run than doing it quickly, and cleaning up the bugs that manifest themselves over the following months.
- vbtemp 10y ago
  Yes, but this is also a false dichotomy. In my experience doing something the "right" way is generally no overhead over doing it the "quick" way. Adding a check, or a log message, or making sure you're using consistent styling, or an assertion before/after some kind of operation... these things don't add time or complication to something
  - dandelany 10y ago
    I strongly disagree. Thinking through and handling all of the edge cases that could break my code inevitably takes more time than getting it to work for the few examples I know of and calling it a day. For example, I just wrote a function to generate a rolling average from a timeseries dataset with one data point per day. All of my sample data has exactly one datum per day. But I just know that eventually there will be an issue that causes data gaps, and of course writing code to handle gaps when they occur takes more time than not doing so and ignoring the consequences. And that's not even mentioning the time required to write unit tests. Furthermore, a lot of the extra time comes not from the initial coding exercise, but the diligence and follow-up required. ie. Cool, I've implemented a feature, but did I go through carefully and ensure that I've removed all my console.logs and commented out experiments? Did I leave dead code anywhere? Did I make any changes that require renaming or refactoring of other parts of the codebase? I never submit a PR these days without carefully going through my own git diff and double-checking myself. I almost always catch something when I do. These things take time.

"Quality? But how does that affect our bottom line?" :)

by VOYD 10y ago

"Quality? But how does that affect our bottom line?" :)

I know you're joking... But it really does affect the bottom line! I've learned the hard way that taking twice as long to do something the right way will be more economical in the long run than doing it quickly, and cleaning up the bugs that manifest themselves over the following months.

vbtemp 10y ago
Yes, but this is also a false dichotomy. In my experience doing something the "right" way is generally no overhead over doing it the "quick" way. Adding a check, or a log message, or making sure you're using consistent styling, or an assertion before/after some kind of operation... these things don't add time or complication to something
- dandelany 10y ago
  I strongly disagree. Thinking through and handling all of the edge cases that could break my code inevitably takes more time than getting it to work for the few examples I know of and calling it a day. For example, I just wrote a function to generate a rolling average from a timeseries dataset with one data point per day. All of my sample data has exactly one datum per day. But I just know that eventually there will be an issue that causes data gaps, and of course writing code to handle gaps when they occur takes more time than not doing so and ignoring the consequences. And that's not even mentioning the time required to write unit tests. Furthermore, a lot of the extra time comes not from the initial coding exercise, but the diligence and follow-up required. ie. Cool, I've implemented a feature, but did I go through carefully and ensure that I've removed all my console.logs and commented out experiments? Did I leave dead code anywhere? Did I make any changes that require renaming or refactoring of other parts of the codebase? I never submit a PR these days without carefully going through my own git diff and double-checking myself. I almost always catch something when I do. These things take time.