The First Rule of Microsoft Excel: Don’t Tell Anyone You’re Good at It

Construct[0].

I used to sneer at such tools, considering them "not real gamedev". That was until, on one local edition of Global Game Jam, a designer in our team did in Construct in 15 minutes what took three of us coders a couple hours. This drove home the point that we were really overcomplicating things by coding a simple game from scratch (in XNA, back then).

--

[0] - https://www.scirra.com/construct2 is the one I played with, but they also seem to have a web version now, for better or worse, which is available at https://www.scirra.com/

> Starts with R? Checks... retrophin.

No. Starts with T. Turing Pharmaceuticals.

You can say what you want about Excel, but it succeeded at something where countless other software failed: Providing a smooth transition between manual data entry and programming and putting it in an interface that's easy to understand while powerful enough to accomplish many interesting tasks.

On a side note, one could say that Tensorflow is a (very) distinct Excel relative, as it also builds up a declarative description of your computation in form of a graph and then figures out how to compute that graph in an efficient manner. Excel is (in my understanding) doing something very similar by analyzing the dataflow between individual cells to compute or update values.

So maybe if we add support for backpropagation into Excel it could make a fantastic deep learning tool :D

I would say that they're _not_ handing you their mental model. Instead using their spreadsheet forces you to come up with a mental model which is congruent to theirs.

The definition of what is BI varies by company and is one of the 'squishier' terms in IT becaise the needs and roles vary quite a bit. In a small company (which it sounds like yours is) one BI person does everything out of necessity. In a Fortune 500 company, a BI person would likely be on a reporting team and spend their days doing nothing but generating reports and performing analysis... there would be another team(s) to deal with ETL, and another to manage the Data Mart(s)/Data Warehouse(s), possibly another for Data Science etc etc. Your IT group sounds a bit dysfunctional, though not atypical: you admit that it's business critical but that the most junior people support it. I'm sure the business loves that (not to mention it's a bad career move for the senior technical people.)

In your company, it sounds like BI is considered to be everything from ETL (which you've got the rough idea of) to providing the final deliverables (reports, analysis, dashboards etc.) to the business customers. Essentially what a BI person would want in that environment are tools with a high degree of leverage for working with the data, probably integrated (seamless workflow, unified metadata), and more geared towards individual productivity rather than group collaboration. Basically, if your BI guy stops showing up for work, the business would be flying blind. He's the person that managers and above go to in order to get the wider view of the business. The requirements fed to him would drive many IT people nuts: 'you know that one-time report you gave us last quarter? Well, we need that same report again this quarter... with these changes... and add the data from this spreadsheet to it. Oh, yeah, there are some gaps in my spreadsheet where we couldn't figure out where to get the numbers... can you fix that?'

Regarding rolling your own ETL tool. Here's an easy way figure out if you really want to (hint: probably not) do this: offer to have your team take over some of the ETL workload from the BI person (i.e. pick a small project or two, learn how to use his tool, see how it works/what it does for him.) If he's good and busy, he'll jump at the offer. That's exactly what you'd be taking on anyway if you decided to roll your own and it's the best vantage point to collect requirements from. I think what you'll find, if you really have ETL/BI needs in your company, is that the requirements are changing far faster than your group would be able to handle. Good ETL/BI tools are generally around the midpoint of custom code (task specific, more structured, managed) and Excel (general purpose, rapid prototyping, free-form, flexible.) Fast turnaround time is the name of the game.

At the end of it you'll probably find you would no more want to write your own ETL tools than you'd want to write your own DBMS. You might event find that, if you have good tools, you want your team to start using them to eliminate some of their custom code. I've been on all sides of the data business (I've rolled my own ETL and reporting tools and used most of the major commercial ones) and when given the option of a decent tool, the tool wins over custom code every time.