4 ms·

Respectfully disagree. Meaningful answers from raw data is hard, but the hardest part was always making business people to _ask the right question_. Take as an

by artyom 3y ago

Respectfully disagree. Meaningful answers from raw data is hard, but the hardest part was always making business people to _ask the right question_. Take as an example a typical business question: "which countries are our users from?" But do they mean the country the user declared in the registration form? Or country they're currently accessing your service from? Or the one from their payment method? Or the one where they where born? Or the one they have citizenship from? Or the one they're currently residing on? Or their shipping address? Or they billing address? Or..? If your dataset is sufficiently big, every one of those countries will output a different answer. I'm sure that in the "global fintech" space those weird cases become the norm. Your typical lower-wage Tableau user will just look for whatever country codes show up and run a count, then declare it the truth. A slightly smarter Tableau user will bribe an engineer to write SQL for them. It'll take someone with knowledge of the dataset and probably the systems where the data is sourced from to push back and force the business to ask the proper question, and provide proper context. Tableau and the like are good to replace "technical work" which is a guy copy/pasting the same SQL query into pgAdmin and emailing the resulting CSV on a daily basis, and then some, but it's not making "less skilled" UI-oriented workers to think better.

specialist 3y ago
> ask the right question Exactly right. As a UI developer, I guess I had always assumed having close contact with end users and domain experts. Nothing I could articulate. It's just how things were done. Then I served in a QA Manager role for a while. Naive me started out focusing on the QC & Test parts. Eventually I figured out most of the value add comes from the Quality Assurance parts. Formalizing some of the stuff I used to do intuitively, like requirements gathering, sure. But I'd say (without proof) most value (impact) came from a) asking the right questions and b) verifying the team solved the problem they had set out to solve. In other words, formalizing the team's internal feedback loops. Alas. That was late 1990s. The Agile Manifesto cult swept aside all that silly formalism. "Too heavy!" We now have "business analysts" backfilling QC/Test, without any training or guideance. And I haven't seen any QA style requirements gathering, analysis, and verification in probably 20 years. As if we can use A/B tests to achieve quality.
- marcosdumay 3y ago
  > The Agile Manifesto cult swept aside all that silly formalism. "Too heavy!" The Agile Manifesto puts close contact with the end users and domain experts as a fundamental principle (actually two principles, out of four). I do think you have the wrong culprit on your mind.
  - specialist 3y ago
    Agreed. When devs, QA, and other doers have a direct line to customers, there's no problem. In my personal experience. That arrangement has been rare. More common is gatekeeping and incompetence. (Which may be the same thing.) -- I've never figured out how to do "agile" QA/QC/Test. I'd don't even know what it'd look like. And, yes, my prior experiences and expectations may be keeping from seeing the new paradigm. Which is why I keep asking. The best candidate I've read about is "Test Into Prod". But I have not yet done that strategy in real life. Soon (fingers crossed). Oh, and "bug bashes", are pretty great. Where everyone examines logs together and either explains or eliminates exceptions. That needs to be the norm.
    - marcosdumay 3y ago
      Well, with Scrum or whatever usually passes as agile, I have no idea either. And I imagine people can't really answer your question, because almost nobody practices the stuff on the manifesto. The motto would be certainly be to bring the customer around to specify your tests, but the actual procedure is a bit hard to imagine the details. Anyawy, my comment was just to point that it's not exactly the manifesto stopping you.

by artyom 3y ago

specialist 3y ago

> ask the right question Exactly right. As a UI developer, I guess I had always assumed having close contact with end users and domain experts. Nothing I could articulate. It's just how things were done. Then I served in a QA Manager role for a while. Naive me started out focusing on the QC & Test parts. Eventually I figured out most of the value add comes from the Quality Assurance parts. Formalizing some of the stuff I used to do intuitively, like requirements gathering, sure. But I'd say (without proof) most value (impact) came from a) asking the right questions and b) verifying the team solved the problem they had set out to solve. In other words, formalizing the team's internal feedback loops. Alas. That was late 1990s. The Agile Manifesto cult swept aside all that silly formalism. "Too heavy!" We now have "business analysts" backfilling QC/Test, without any training or guideance. And I haven't seen any QA style requirements gathering, analysis, and verification in probably 20 years. As if we can use A/B tests to achieve quality.

marcosdumay 3y ago
> The Agile Manifesto cult swept aside all that silly formalism. "Too heavy!" The Agile Manifesto puts close contact with the end users and domain experts as a fundamental principle (actually two principles, out of four). I do think you have the wrong culprit on your mind.
- specialist 3y ago
  Agreed. When devs, QA, and other doers have a direct line to customers, there's no problem. In my personal experience. That arrangement has been rare. More common is gatekeeping and incompetence. (Which may be the same thing.) -- I've never figured out how to do "agile" QA/QC/Test. I'd don't even know what it'd look like. And, yes, my prior experiences and expectations may be keeping from seeing the new paradigm. Which is why I keep asking. The best candidate I've read about is "Test Into Prod". But I have not yet done that strategy in real life. Soon (fingers crossed). Oh, and "bug bashes", are pretty great. Where everyone examines logs together and either explains or eliminates exceptions. That needs to be the norm.
  - marcosdumay 3y ago
    Well, with Scrum or whatever usually passes as agile, I have no idea either. And I imagine people can't really answer your question, because almost nobody practices the stuff on the manifesto. The motto would be certainly be to bring the customer around to specify your tests, but the actual procedure is a bit hard to imagine the details. Anyawy, my comment was just to point that it's not exactly the manifesto stopping you.