Live data from Hacker News

Tableau stock down almost 50%

google.com

341–350 of 370 posts

Re: Tableau stock down almost 50%

#341

Earlier quoted context omitted.

Mondrian and Pentaho was a disaster for us, and Pentaho were pretty aggressive about trying to sell us a support contract to fix it

What were the technical problems causing the disaster if you can share?

We jettisoned Pentaho about 2 years ago because of the effort required to develop and maintain it.

At the time, between the ETL and reporting layers, it acted more like a set of different open source apps simply branded together, and interop required more effort than what should have been necessary.

Debugging was a nightmare as well. Huge stack traces on simple errors made locating problems difficult, and there seemed to be little information in the community. The number of Java library layers spewing out on a simple JDBC driver error was mind-boggling. Pentaho of course has a interest in revenue from support contracts, and most inquiries into simple issues in the forums led down that path. It may have gotten better since, but there was a long way to go.

We switched to Tableau on the front end, and "old fashioned" ETL scripting in Python (now some Go) on the backend. At the same point today I would consider something like R/Shiny, but for speed of implementation Tableau would also be a contender.

Re: Tableau stock down almost 50%

#342

Earlier quoted context omitted.

Also to clarify, the licence is $1000 for the first purchase. Subsequently, you only have to pay the maintenance fees of about usd 200 per year to remain eligible for support and upgrades. You can still continue using the latest version you were on in perpetuity.

How much for licensing the server itself?

I don't know any of the server costs. We pull our data off our own servers and handle all of that ourselves.

Re: Tableau stock down almost 50%

#343

Earlier quoted context omitted.

PowerBI may be subsidized or not. But in our use-cases and in their documentation, it really doesn't funnel customers to SQL Server. Sure, it plays nice with SQL, SSAS/MD and SSAS/Tabular. But it also plays nice with many, many other data sources individually and in mashup. Its internal data modeling and ETL capabilities rival the power of SSAS and SSIS and they are free -- I see them as more of a competitor to SQL t…

You may, but that's not how the strategy guys at Microsoft see it, according to their own words. Data modeling and ETL capabilities rival SSAS and SSIS only in very trivial scenarios. I'm not saying that to bash on PowerBI. I love that product and use it heavily and promote it to clients. It just serves different purposes than Tableau.

The data modeling engine IS SSAS. The only major missing pieces are row-level security and defined KPIs. The query language, DAX, and the backing columnstore database are the same engine used in SSAS Tabular.

Re: Tableau stock down almost 50%

#344

Earlier quoted context omitted.

You may, but that's not how the strategy guys at Microsoft see it, according to their own words. Data modeling and ETL capabilities rival SSAS and SSIS only in very trivial scenarios. I'm not saying that to bash on PowerBI. I love that product and use it heavily and promote it to clients. It just serves different purposes than Tableau.

The data modeling engine IS SSAS. The only major missing pieces are row-level security and defined KPIs. The query language, DAX, and the backing columnstore database are the same engine used in SSAS Tabular.

xVelocity is only a (small) part of SSAS and it has a very limited application compared to OLAP even in the upcoming 2016 edition which greatly enhances the columnar store functionality.

Re: Tableau stock down almost 50%

#345

Earlier quoted context omitted.

This. BI in large corporations is usually done by people having no clue about the data, producing bullshit results, leading to "insights" to management (who at that point have have no clue that all the cost columns were added up, regardless of currency), leading to a final "product strategy" that gets implemented over the next years, while in all the companies still producing innovation, this is usually done by a rog…

I was a SI/BI engineer for a while; let me chime in to defend my people just a little bit :) Certainly there are lots of bullshit metrics, there is often very little desire to audit data or even do a by hand sanity check once and a while. That being said, there were _many_ engineers who actually gave a fuck about making sure we had telemetry in actionable, meaningful, and appropriate places, and unfrotunately the gap…

While what I said was actually an amalgamation of true stories I've seen myself, I was certainly exaggerating a bit :)

I think a lot of things come together for this pattern, which definitely happens quite a lot. Best predictor for this scenario is a clear divide between product and BI people, usually exacerbated by the fact that non-technical people get hired for BI.

Group bias by backend engineers who see BI as "just some point and click" which isn't really that challenging (but usually much better paid, as they are catering sales/bizdev/C-level which is always closer to the money) also doesn't help.

Also, as you say, often times the value of BI doesn't trickle back down the chain and that way, tracking is at most a second thought for application engineers when going prod.

Having built two analytics stacks myself (and seen the perspectives from BI, backend, sales and marketing alike) these are exactly the drivers we tackled first at our current company.

Our recipes against this common failure are: Marketing directly working with product engineers for their tracking requirements (with just some coaching from tracking pros) - and dual-using our analytics stack (Snowplow -> Redshift) for both operations (user segmenting, push notifications) and business intelligence.

This is usually considered a big no-no in BI circles which all tend to duplicate data to be on the safe side, but it helps immensely to make sure product and engineering are just as interested in data quality as the BI guys, as they depend on the very same data.

It's certainly not for everyone, but for us, it works really well.

Re: Tableau stock down almost 50%

#346

Earlier quoted context omitted.

This. BI in large corporations is usually done by people having no clue about the data, producing bullshit results, leading to "insights" to management (who at that point have have no clue that all the cost columns were added up, regardless of currency), leading to a final "product strategy" that gets implemented over the next years, while in all the companies still producing innovation, this is usually done by a rog…

wow. i've only ever worked at small companies, and i guess to avoid things like this is why, but i can't help but wonder how common this is, and if in fact no one has ever used BI effectively. i find that hard to believe but really i have no idea, and its an interesting thought, makes you want to chuckle or shake your head or both.

Of course I wouldn't go so far as to say no one has ever used it effectively, but it seems like in the vast majority of cases, it's bullshit all the way down.

It's a surreal experience when you realize how executives are making decisions based on something that, after a moment of critical thought and common sense, clearly has no more relevance than some integers pulled out of rand(). Chuckle and shake your head is indeed about all you can do.

Just try not to visibly smirk if you're ever involved in acquisition talks. Play along.

Re: Tableau stock down almost 50%

#347
post #341

Earlier quoted context omitted.

What were the technical problems causing the disaster if you can share?

We jettisoned Pentaho about 2 years ago because of the effort required to develop and maintain it. At the time, between the ETL and reporting layers, it acted more like a set of different open source apps simply branded together, and interop required more effort than what should have been necessary. Debugging was a nightmare as well. Huge stack traces on simple errors made locating problems difficult, and there seeme…

Basically same here, but a few years earlier. I consider a three hundred line stack trace to be a valid reason to replace a system with something less operationally challenging. When engineers are $100+/hr, and some way more than that, it often ends up being cheaper as well.

Re: Tableau stock down almost 50%

#348
post #339

Earlier quoted context omitted.

> And I have to put stuff in SQL and do the plumbing if I need any meaningful preprocessing. Actually, the plumbing isn't as difficult as most people make it out to be. Nowadays, its the era of abstraction and FOSS infrastructure tools like jQuery, Bootstrap and like you mentioned, Highcharts. I'm a freelancer who quite recently developed a Tableau replacement for one of my clients. This client realized that all he b…

I'm similar, but use D3

jqplot is what I use extensively. I haven't used D3 yet, but heard that it takes a lot more initial coding to come up with even a basic line/bar chart.

Re: Tableau stock down almost 50%

#349

Earlier quoted context omitted.

This. Freelancing is the future. Hiring in-house developers, or better still, freelance programmers will ensure that you will have custom-built your maximum BI tools and with a reasonable price. Of course, finding and hiring good freelancers who are not only dedicated in their craft, but also reasonably priced is a bit involved task, but certainly doable.

>custom-built your maximum BI tools and with a reasonable price Have you ever really seen that happen? Not me.

> Have you ever really seen that happen? Not me.

In 99% cases, that happens because your requirements change. If you hire a competent developer, the total cost of development is always a pittance compared to what you pay monthly/quarterly to a product based company.

Re: Tableau stock down almost 50%

#350
post #347
post #341

Earlier quoted context omitted.

We jettisoned Pentaho about 2 years ago because of the effort required to develop and maintain it. At the time, between the ETL and reporting layers, it acted more like a set of different open source apps simply branded together, and interop required more effort than what should have been necessary. Debugging was a nightmare as well. Huge stack traces on simple errors made locating problems difficult, and there seeme…

Basically same here, but a few years earlier. I consider a three hundred line stack trace to be a valid reason to replace a system with something less operationally challenging. When engineers are $100+/hr, and some way more than that, it often ends up being cheaper as well.

The record setter I saw was 1,500 lines from two JDBC exceptions.
Post reply on HN