9 ms·

Exactly. A bad workman always blames his tools.

by wyday 13y ago

klodolph 13y ago
Partly because a bad workman chooses poor tools to begin with. Tools do matter. It's easier to find a mistake in say, an SQL query or some R code than it is to find a mistake in an Excel spreadsheet, where you are trying to catch the difference between SUM(A3:A12) and SUM(A3:A10) in a thousand different cells.
- niggler 13y ago
  > where you are trying to catch the difference between SUM(A3:A12) and SUM(A3:A10) in a thousand different cells. Excel does a pretty good job in highlighting which cells are selected when you edit a formula, and it does a pretty good job of maintaining the meaning of the formula under sheet transformations. For example, if you inserted a row between rows 8 and 9 then the two formulae would be =SUM(A3:A13) and =SUM(A3:A11) respectively. This may have been a genuine error, but the two researchers definitely started the process with a goal in mind, and when the results agreed with their goals they didn't bother to check.
  - klodolph 13y ago
    Yes, it does highlight the cells. But if a mistake does somehow make it in, it is still exceptionally tedious to find the error. It is easy enough to expand a formula for additional cells but accidentally miss a cell, leaving it with the old formula. If you were using SQL, R, or Python, this class of error would never happen.
    - niggler 13y ago
      Recent versions of excel do warn you if formulas omit adjacent cells. I agree with your sentiment to some extent but with excel 2011/2013 you have to actively suppress these warnings.
    - flatfilefan 13y ago
      I guess it is just that to do a proper audit you need to have your logic on one page. Otherwise it is extreemly hard to follow the code. In excel every formula is sitting essentially on it's own page. It is easy to code this way but hard to audit.
  - yummyfajitas 13y ago
    This may have been a genuine error, but the two researchers definitely started the process with a goal in mind... What would that goal be? According to Megan Mcardle, Rogoff was a mild proponent of stimulus. For example, he said this in 2012: "Back in 2008-9, there was a reasonable chance, maybe 20% that we’d end up in another Great Depression. Spending a trillion dollars is nothing to knock that off the table." http://www.thedailybeast.com/articles/2013/04/17/did-reinhart-and-rogoff-flub-a-major-statistic.html http://www.thedailybeast.com/articles/2013/04/17/did-reinhar...
- UnoriginalGuy 13y ago
  I'm not sure I understand why it is easier with SQL than Excel. Both seem to offer similar roadblocks and both seem to offer similar solutions. I think we're thinking there is a technological solution to a human problem, and personally I don't think there is or could ever be. This is a process problem. And by process I mean the process of building complex datasets, validating them for "correctness," and judging the quality/correctness of different data sets. Unit tests are a massive asset to programmers. I wonder if unit tests (i.e. "sanity checks") would also help in this situation? I mean you would have to force people to write them and monitor them, but once they've been created they pay for themselves by picking up unexpected errors.
  - mbreese 13y ago
    One of the big problems with science is the proliferation of Excel "databases". It is very easy to look at a lot of numbers and make quick calculations with them. However, when you start getting into extremely large datasets, your propensity to make mistakes increases. A2:A10 here, B3:B11 there, etc... This is one reason why recent versions of Excel warn you when your formulas aren't in sync. However, all of this is fixed when you are using SQL to properly query a database. Why? Because you are forced to write a SQL statement that details exactly what you want done. With Excel it can all be hidden away behind the cells. With SQL, it's out in front, so it's easier to check. People like to use Excel because they can get an answer quickly without all that "programming". The problems start to arise when you need better tools, but only know Excel. So, in this case, it's not a matter of a craftsman blaming their tools, it's closer to an amateur trying to pretend to be a professional. Excel is a wonderful spreadsheet. It is a horrible database.
    - UnoriginalGuy 13y ago
      Unless you write SQL queries that use stored procedures or pre-calculated results tables, and then you just wind up in the same situation as Excel. I mean Excel is at its heart a query language. So your logic equally applies to Excel, why not write a massive query in Excel that does all the calculations in one go so you can see the inner workings? All you're really doing is playing musical chairs with the data. SQL query language for Excel query language, and data moved from tables to worksheets. As I said earlier, unless there are procedural changes upstream nothing will change. A tool is just a tool. You can use it in a way to minimise mistakes, or not. Humans are the weak point. Now there are tools that automatically identify common mistakes but neither Excel or SQL/relational database engines are in that class.
pseut 13y ago
R&R haven't blamed excel. But I think it's fair game to criticize another workman's tool choice if it played a role in a mistake.

Exactly. A bad workman always blames his tools.

by wyday 13y ago

Exactly. A bad workman always blames his tools.

Partly because a bad workman chooses poor tools to begin with. Tools do matter. It's easier to find a mistake in say, an SQL query or some R code than it is to find a mistake in an Excel spreadsheet, where you are trying to catch the difference between SUM(A3:A12) and SUM(A3:A10) in a thousand different cells.

niggler 13y ago
> where you are trying to catch the difference between SUM(A3:A12) and SUM(A3:A10) in a thousand different cells. Excel does a pretty good job in highlighting which cells are selected when you edit a formula, and it does a pretty good job of maintaining the meaning of the formula under sheet transformations. For example, if you inserted a row between rows 8 and 9 then the two formulae would be =SUM(A3:A13) and =SUM(A3:A11) respectively. This may have been a genuine error, but the two researchers definitely started the process with a goal in mind, and when the results agreed with their goals they didn't bother to check.
- klodolph 13y ago
  Yes, it does highlight the cells. But if a mistake does somehow make it in, it is still exceptionally tedious to find the error. It is easy enough to expand a formula for additional cells but accidentally miss a cell, leaving it with the old formula. If you were using SQL, R, or Python, this class of error would never happen.
  - niggler 13y ago
    Recent versions of excel do warn you if formulas omit adjacent cells. I agree with your sentiment to some extent but with excel 2011/2013 you have to actively suppress these warnings.
  - flatfilefan 13y ago
    I guess it is just that to do a proper audit you need to have your logic on one page. Otherwise it is extreemly hard to follow the code. In excel every formula is sitting essentially on it's own page. It is easy to code this way but hard to audit.
- yummyfajitas 13y ago
  This may have been a genuine error, but the two researchers definitely started the process with a goal in mind... What would that goal be? According to Megan Mcardle, Rogoff was a mild proponent of stimulus. For example, he said this in 2012: "Back in 2008-9, there was a reasonable chance, maybe 20% that we’d end up in another Great Depression. Spending a trillion dollars is nothing to knock that off the table." http://www.thedailybeast.com/articles/2013/04/17/did-reinhart-and-rogoff-flub-a-major-statistic.html http://www.thedailybeast.com/articles/2013/04/17/did-reinhar...
UnoriginalGuy 13y ago
I'm not sure I understand why it is easier with SQL than Excel. Both seem to offer similar roadblocks and both seem to offer similar solutions. I think we're thinking there is a technological solution to a human problem, and personally I don't think there is or could ever be. This is a process problem. And by process I mean the process of building complex datasets, validating them for "correctness," and judging the quality/correctness of different data sets. Unit tests are a massive asset to programmers. I wonder if unit tests (i.e. "sanity checks") would also help in this situation? I mean you would have to force people to write them and monitor them, but once they've been created they pay for themselves by picking up unexpected errors.
- mbreese 13y ago
  One of the big problems with science is the proliferation of Excel "databases". It is very easy to look at a lot of numbers and make quick calculations with them. However, when you start getting into extremely large datasets, your propensity to make mistakes increases. A2:A10 here, B3:B11 there, etc... This is one reason why recent versions of Excel warn you when your formulas aren't in sync. However, all of this is fixed when you are using SQL to properly query a database. Why? Because you are forced to write a SQL statement that details exactly what you want done. With Excel it can all be hidden away behind the cells. With SQL, it's out in front, so it's easier to check. People like to use Excel because they can get an answer quickly without all that "programming". The problems start to arise when you need better tools, but only know Excel. So, in this case, it's not a matter of a craftsman blaming their tools, it's closer to an amateur trying to pretend to be a professional. Excel is a wonderful spreadsheet. It is a horrible database.
  - UnoriginalGuy 13y ago
    Unless you write SQL queries that use stored procedures or pre-calculated results tables, and then you just wind up in the same situation as Excel. I mean Excel is at its heart a query language. So your logic equally applies to Excel, why not write a massive query in Excel that does all the calculations in one go so you can see the inner workings? All you're really doing is playing musical chairs with the data. SQL query language for Excel query language, and data moved from tables to worksheets. As I said earlier, unless there are procedural changes upstream nothing will change. A tool is just a tool. You can use it in a way to minimise mistakes, or not. Humans are the weak point. Now there are tools that automatically identify common mistakes but neither Excel or SQL/relational database engines are in that class.

pseut 13y ago

R&R haven't blamed excel. But I think it's fair game to criticize another workman's tool choice if it played a role in a mistake.