4 ms·

You laugh, but I bet Excel produces orders of magnitude more real "business intelligence" than all other "BI" tools combined.

by m0zg 6y ago

capsulecorp 6y ago
You bet, but I'd really love to see data that supports that.
GuB-42 6y ago
Here is an anecdote. I had to work on a tool that shows what's wrong with an assembly line: missing parts, delays, etc... So that management can take corrective action. Typical "BI" stuff but in a more industrial setting. The company went all out on new technologies. Web front-end, responsive design, "big data", distributed computing, etc... My job was to use PySpark to extract indicators from a variety of data sources. Nothing complex, but the development environment was so terrible it turned the most simple task into a challenge. One day, the project manager (sorry, "scrum master") came in, opened an excel sheet, imported the data sets, and in about 5 minutes, showed me what I had to do. It took me several days to implement... So basically, my manager with Excel was hundreds of times more efficient than I was with all that shiny new technology. That experience made me respect Excel and people who know how to use it a lot more, and modern stacks a lot less. I am fully aware that Excel is not always the right tool for the job, and that modern stacks have a place. For example, Excel does not scale, but there are cases where you don't need scalability. An assembly line isn't going to start processing 100x more parts anytime soon, and one that does will be very different. There are physical limits.
- yomly 6y ago
  Well in these situations, the implicit ask of your company (I've been there myself) is to basically rebuild excel but replace some of the power/flexibility of excel for safety and to remove the risk of error away from front end users (aka move the risk to the back end developers) Unfortunately which specific features of Excel are acceptable to remove are unknown until you have already way over invested into the project. The best I've seen this done is having Excel as a client for your data store. Where read access is straightforward and write can be done via csv upload (and heavy validation and maybe history rollback). That way the business can self-service every permutation of dashboard/report they need and only when a very specific usecase arises do you need to start putting engineering effort behind it. I suppose you can also supplement the Excel workflow with a pared down CRUD interface for the inevitable employee allergic to excel.
  - tjalfi 6y ago
    I posted elsewhere[0] in this thread about my employer's successful practice of replacing shared spreadsheets with web applications. Here is another option that we use instead of CSV import. Our applications support custom reports and custom fields. Users can define new reports and run them on demand. They can also define custom field types with validation, data entry support, etc. This combination provides some of the extensibility of Excel while retaining the advantages of an application. Edited for wording changes. [0] https://news.ycombinator.com/item?id=23292374 https://news.ycombinator.com/item?id=23292374
- kqr 6y ago
  I think you drew the right conclusion from your experience, but I also want to point out that building the first prototype is always anywhere from one to three orders of magnitude easier than building the actual product. The devil is in the details, and software is nothing but details. The product owner at the company I work for likens it (somewhat illogically, but it works) with constructing walls. You can either pick whatever stones you have lying around, and then you'll spend a lot of time trying to fit them together and you'll have a hell of a time trying to repair the wall when a section breaks. Or you can build it from perfectly rectangular bricks, and it will be easy to make it taller one layer at a time. Using whatever rocks you have lying around is like building a prototype in Excel. Carefully crafting layers of abstraction using proper software engineering procedures means taking the time to make those rectangular bricks before building the wall. End result more predictable when life happens to the wall.
jtdev 6y ago
...And orders of magnitude more wasted time and capital due to inaccurate and isolated data.
- tjalfi 6y ago
  People use what they know to solve the problems they have. You can complain about their solution or see it as an opportunity. I posted elsewhere[0] in this thread about my employer's practice of replacing shared spreadsheets with web applications. This approach works quite well for us and I would encourage you to consider it as an option. [0] https://news.ycombinator.com/item?id=23292374 https://news.ycombinator.com/item?id=23292374

You laugh, but I bet Excel produces orders of magnitude more real "business intelligence" than all other "BI" tools combined.

by m0zg 6y ago

You laugh, but I bet Excel produces orders of magnitude more real "business intelligence" than all other "BI" tools combined.

capsulecorp 6y ago

You bet, but I'd really love to see data that supports that.

GuB-42 6y ago

Here is an anecdote. I had to work on a tool that shows what's wrong with an assembly line: missing parts, delays, etc... So that management can take corrective action. Typical "BI" stuff but in a more industrial setting. The company went all out on new technologies. Web front-end, responsive design, "big data", distributed computing, etc... My job was to use PySpark to extract indicators from a variety of data sources. Nothing complex, but the development environment was so terrible it turned the most simple task into a challenge. One day, the project manager (sorry, "scrum master") came in, opened an excel sheet, imported the data sets, and in about 5 minutes, showed me what I had to do. It took me several days to implement... So basically, my manager with Excel was hundreds of times more efficient than I was with all that shiny new technology. That experience made me respect Excel and people who know how to use it a lot more, and modern stacks a lot less. I am fully aware that Excel is not always the right tool for the job, and that modern stacks have a place. For example, Excel does not scale, but there are cases where you don't need scalability. An assembly line isn't going to start processing 100x more parts anytime soon, and one that does will be very different. There are physical limits.

yomly 6y ago
Well in these situations, the implicit ask of your company (I've been there myself) is to basically rebuild excel but replace some of the power/flexibility of excel for safety and to remove the risk of error away from front end users (aka move the risk to the back end developers) Unfortunately which specific features of Excel are acceptable to remove are unknown until you have already way over invested into the project. The best I've seen this done is having Excel as a client for your data store. Where read access is straightforward and write can be done via csv upload (and heavy validation and maybe history rollback). That way the business can self-service every permutation of dashboard/report they need and only when a very specific usecase arises do you need to start putting engineering effort behind it. I suppose you can also supplement the Excel workflow with a pared down CRUD interface for the inevitable employee allergic to excel.
- tjalfi 6y ago
  I posted elsewhere[0] in this thread about my employer's successful practice of replacing shared spreadsheets with web applications. Here is another option that we use instead of CSV import. Our applications support custom reports and custom fields. Users can define new reports and run them on demand. They can also define custom field types with validation, data entry support, etc. This combination provides some of the extensibility of Excel while retaining the advantages of an application. Edited for wording changes. [0] https://news.ycombinator.com/item?id=23292374 https://news.ycombinator.com/item?id=23292374
kqr 6y ago
I think you drew the right conclusion from your experience, but I also want to point out that building the first prototype is always anywhere from one to three orders of magnitude easier than building the actual product. The devil is in the details, and software is nothing but details. The product owner at the company I work for likens it (somewhat illogically, but it works) with constructing walls. You can either pick whatever stones you have lying around, and then you'll spend a lot of time trying to fit them together and you'll have a hell of a time trying to repair the wall when a section breaks. Or you can build it from perfectly rectangular bricks, and it will be easy to make it taller one layer at a time. Using whatever rocks you have lying around is like building a prototype in Excel. Carefully crafting layers of abstraction using proper software engineering procedures means taking the time to make those rectangular bricks before building the wall. End result more predictable when life happens to the wall.

jtdev 6y ago

...And orders of magnitude more wasted time and capital due to inaccurate and isolated data.

tjalfi 6y ago
People use what they know to solve the problems they have. You can complain about their solution or see it as an opportunity. I posted elsewhere[0] in this thread about my employer's practice of replacing shared spreadsheets with web applications. This approach works quite well for us and I would encourage you to consider it as an option. [0] https://news.ycombinator.com/item?id=23292374 https://news.ycombinator.com/item?id=23292374