5 ms·

It happens. I work in corporate finance and am presenting boring spreadsheet stuff daily. I/My team makes mistakes too and I don’t always catch them before the

It happens. I work in corporate finance and am presenting boring spreadsheet stuff daily. I/My team makes mistakes too and I don’t always catch them before the presentation. Sometimes there’s literally no time it’s like dev on prod without tests. Anyways, what you did is very common. Many people are actively looking for mistakes in the math instead of focusing on the content of the presentation. And will derail my entire meeting when they find one. Just word of warning , don’t be that guy. Usually it’s some unimportant metric (or someone would have noticed) and directional correctness facilitates the same conversation. For example, oh you’re right overtime is running at 10% instead of 8% is usually not a material fact when your department is 30% over budget and some productivity metric is where the businesses focus needs to be (eg. widgets/hour). Instead, bring it to my attention after the fact. Or shoot me a email while in the meeting. Only verbalize it if it’s crucial to the conversation or impacts the decision being made. It’s a bit like expecting bug free software, it’s just impossible. Not saying you handled it wrong perse, most people do this. Just suggesting how I have been on the other side of this and prefer for others to act. I find this more professional as I wouldn’t turn up to your product launch party and just tell everyone in the room about the GitHub issues log. Or, as another example, if I were your manager, I wouldn’t call you out publicly but assume you prefer a private feedback session when you screw something up.

kragen 5y ago
If it isn't important whether the numbers are real or fake, why show them? To intimidate people with a baseless appearance of mathematical rigor? If so, I'd say the people who point out that they're fake are doing a service to the decisionmakers in the meeting, though it's unsurprising that the presenters don't appreciate it.
- curiousllama 5y ago
  You've never shipped with known bugs? If someone asked you "If it isn't important whether the software works or not, why ship it?", what would your reaction be? Note: > Directional correctness facilitates the same conversation
  - Jensson 5y ago
    A math error in a spreadsheet can change the entire conclusion to be drawn from the data, it is very different from known bugs users can work around.
    - conductr 5y ago
      But both can only be ascertained in hindsight and knowledge of the issue. Software issues can, and do, also cause a lot of issues with the data that spreadsheets are analyzing so I don’t necessarily see it as different. Also a lot of spreadsheet info is just info. It’s not necessarily being used as a crucial decision criteria. There’s such a wide spectrum of situations it’s hard to be too rigid with this. My software analogy was just pandering to this audience. Probably not a perfect analogy.
  - kragen 5y ago
    I would say that most software doesn't have to be correct to be useful. There are exceptions, like anything to do with cryptography. You might say that the same can be true of calculations; after all, calculations about the contingent universe (as opposed to, say, number theory) are always based on data incorporating some uncertainty. But there are two key differences: ① I don't put up a slide showing all the intermediate values of the variables in my program in order to make an argument for something. Instead, I try to show my chain of reasoning in enough detail to be convincing and to expose any relevant potentially incorrect assumptions or reasoning steps I've made so that others can find my errors, without including trivial or irrelevant details. Including trivial and irrelevant details makes it harder, not easier, to find relevant incorrect assumptions or reasoning steps. That's why I question the motivation of people who include those in their slides: it sounds like they're attempting to make their argument so complex that there are no obvious errors, rather than so simple that there are obviously no errors. ② A 10% uncertainty in an input datum can be traced through the calculation from beginning to end and will often result in a 10% or 21% uncertainty in the result, or even less. (And where that's not the case the sensitivity should be called out.) A calculation that's simply incorrect—for example, treating millions as thousands, or forgetting to divide by the relevant denominator—commonly produces results that are off by multiple orders of magnitude.
- treeman79 5y ago
  For a couple of years I would always include an obvious UI fix in my presentations with senior management. I always got my plans approved the first time. Management was always so happy to contribute something that they didn’t question anything I actually wanted. They never caught on. This was for CEO of a fortune 100
  - nayuki 5y ago
    Related: https://blog.codinghorror.com/new-programming-jargon/#5 https://blog.codinghorror.com/new-programming-jargon/#5 , https://softwareengineering.stackexchange.com/questions/168146/what-is-the-term-for-a-decoy-feature-or-intentional-bug https://softwareengineering.stackexchange.com/questions/1681...
  - conductr 5y ago
    Yeah on the flip side of my comment I’ve known some finance guys that bury in mistakes just to see if anyone catches them. Obviously not on super official filings. But internal management stuff. One boss of mine early on in my career gave out prizes. It was their way of making interactive
- conductr 5y ago
  I have to answer in the context I’m familiar with, finance. People start aimlessly hypothesizing if you don’t show them the nonissues. Also, management is conditioned to look at certain key things in combination because they are in fact interconnected. So for example, is the core issue is profit is lower than budgeted. I will show them sales are on plan. I will show them non labor is on plan. Then I will say now labor is the problem. Overtime is immaterial , but our hours/widget KPI seem way high. We call the plant manager and find out an automation process is down. Because it’s so costly, we fly in a support tech that night to fix it. Seems simple enough but in an enterprise this could involve a dozen people and move slowly unless I craft the story of how much this issue is costing us. And since I’m not in the plant, I didn’t even know the problem that I was pointing out to begin with. I probably don’t even know who the plant manager or his boss is. So it’s not like I can just pick up the phone and figure out the whole story (but generally would try to).
  - kragen 5y ago
    Thank you for explaining! In that case it seems like it would be worthwhile to sort out the mistakes in the calculation in order to figure out which of the seemingly implausible figures are in fact correct and which are just calculation errors?
    - conductr 5y ago
      There’s a lot of conditions that come into play. If I’m actively in the meeting and the number is obviously wrong and I have no analyst support (usually at the point). I’ll just table it and apologize and send a follow up to the attendees after the meeting and summarize whether I feel like the correct calculation impacts our decisions/discussion. These things do have a reputational cost so it’s my job to see that myself and my team and putting out error free stuff and having it proofread and such is usually the best we can do. There are many times when the math is in fact correct and the numbers are just implausible. That’s usually the meat of the meeting and something to dig deeper on. Hopefully we noticed it, double checked it, and it’s one of my talking points to address in the meeting. Either I want to point it out and explain why or point it out and ask why depending on who I’m talking to.

kragen 5y ago

If it isn't important whether the numbers are real or fake, why show them? To intimidate people with a baseless appearance of mathematical rigor? If so, I'd say the people who point out that they're fake are doing a service to the decisionmakers in the meeting, though it's unsurprising that the presenters don't appreciate it.

curiousllama 5y ago
You've never shipped with known bugs? If someone asked you "If it isn't important whether the software works or not, why ship it?", what would your reaction be? Note: > Directional correctness facilitates the same conversation
- Jensson 5y ago
  A math error in a spreadsheet can change the entire conclusion to be drawn from the data, it is very different from known bugs users can work around.
  - conductr 5y ago
    But both can only be ascertained in hindsight and knowledge of the issue. Software issues can, and do, also cause a lot of issues with the data that spreadsheets are analyzing so I don’t necessarily see it as different. Also a lot of spreadsheet info is just info. It’s not necessarily being used as a crucial decision criteria. There’s such a wide spectrum of situations it’s hard to be too rigid with this. My software analogy was just pandering to this audience. Probably not a perfect analogy.
- kragen 5y ago
  I would say that most software doesn't have to be correct to be useful. There are exceptions, like anything to do with cryptography. You might say that the same can be true of calculations; after all, calculations about the contingent universe (as opposed to, say, number theory) are always based on data incorporating some uncertainty. But there are two key differences: ① I don't put up a slide showing all the intermediate values of the variables in my program in order to make an argument for something. Instead, I try to show my chain of reasoning in enough detail to be convincing and to expose any relevant potentially incorrect assumptions or reasoning steps I've made so that others can find my errors, without including trivial or irrelevant details. Including trivial and irrelevant details makes it harder, not easier, to find relevant incorrect assumptions or reasoning steps. That's why I question the motivation of people who include those in their slides: it sounds like they're attempting to make their argument so complex that there are no obvious errors, rather than so simple that there are obviously no errors. ② A 10% uncertainty in an input datum can be traced through the calculation from beginning to end and will often result in a 10% or 21% uncertainty in the result, or even less. (And where that's not the case the sensitivity should be called out.) A calculation that's simply incorrect—for example, treating millions as thousands, or forgetting to divide by the relevant denominator—commonly produces results that are off by multiple orders of magnitude.
treeman79 5y ago
For a couple of years I would always include an obvious UI fix in my presentations with senior management. I always got my plans approved the first time. Management was always so happy to contribute something that they didn’t question anything I actually wanted. They never caught on. This was for CEO of a fortune 100
- nayuki 5y ago
  Related: https://blog.codinghorror.com/new-programming-jargon/#5 https://blog.codinghorror.com/new-programming-jargon/#5 , https://softwareengineering.stackexchange.com/questions/168146/what-is-the-term-for-a-decoy-feature-or-intentional-bug https://softwareengineering.stackexchange.com/questions/1681...
- conductr 5y ago
  Yeah on the flip side of my comment I’ve known some finance guys that bury in mistakes just to see if anyone catches them. Obviously not on super official filings. But internal management stuff. One boss of mine early on in my career gave out prizes. It was their way of making interactive
conductr 5y ago
I have to answer in the context I’m familiar with, finance. People start aimlessly hypothesizing if you don’t show them the nonissues. Also, management is conditioned to look at certain key things in combination because they are in fact interconnected. So for example, is the core issue is profit is lower than budgeted. I will show them sales are on plan. I will show them non labor is on plan. Then I will say now labor is the problem. Overtime is immaterial , but our hours/widget KPI seem way high. We call the plant manager and find out an automation process is down. Because it’s so costly, we fly in a support tech that night to fix it. Seems simple enough but in an enterprise this could involve a dozen people and move slowly unless I craft the story of how much this issue is costing us. And since I’m not in the plant, I didn’t even know the problem that I was pointing out to begin with. I probably don’t even know who the plant manager or his boss is. So it’s not like I can just pick up the phone and figure out the whole story (but generally would try to).
- kragen 5y ago
  Thank you for explaining! In that case it seems like it would be worthwhile to sort out the mistakes in the calculation in order to figure out which of the seemingly implausible figures are in fact correct and which are just calculation errors?
  - conductr 5y ago
    There’s a lot of conditions that come into play. If I’m actively in the meeting and the number is obviously wrong and I have no analyst support (usually at the point). I’ll just table it and apologize and send a follow up to the attendees after the meeting and summarize whether I feel like the correct calculation impacts our decisions/discussion. These things do have a reputational cost so it’s my job to see that myself and my team and putting out error free stuff and having it proofread and such is usually the best we can do. There are many times when the math is in fact correct and the numbers are just implausible. That’s usually the meat of the meeting and something to dig deeper on. Hopefully we noticed it, double checked it, and it’s one of my talking points to address in the meeting. Either I want to point it out and explain why or point it out and ask why depending on who I’m talking to.