"A composable build system for reproducible environments"
Is there another meaning of kurtosis that is applicable to this product? Kurtosis is used to describe aspects of probability distributions' tails/flatness.
Ahh this is the closest one to what we originally meant haha..(founder here). but the intent was to mitigate the impact of “kurtosis” on your system by enabling engineers to see how the whole environment worked in testing (and other parts of the development process). We also have a love for taleb’s books about excelling in uncertainty, in high “Kurtosis” environments, so going with the theme made sense for us.
But I see from the comments it is decently confusing!
(Founder here) I love the thought! We definitely have a smoother understanding of the name from the users in that space from anecdotal experience, but actually it comes from both our own love of the concepts in the book “antifragile” by Taleb that talks about excelling in volatile (high Kurtosis) environments, plus the fact that our first users used it for E2E test environments which we imagined were catching “tail risk” bugs between components.
Although I see how the overloading of the term is pretty confusing here
I think this is yet another example of developers coming up with bad names for things. People seem to love using highly specific, technical terms for their projects which seem only vaguely/tangentially related to the proper meaning of the term.
I think it’s a way of borrowing the credibility attached to the term. But at the same time it dilutes the original meaning of the term and confuses people over time.
And it just gives a shitty search experience. You don't want people finding math stuff instead when searching for your product and people searching for math don't want to find some unrelated software.
Founder here…have definitely seen this. Trying to find some of our users’ open source work on public GitHub repos to see what they’re doing can be tricky because it does pop up a lot of data science / stats work that’s totally unrelated!
Hey, one of the founders here! As Galen mentioned in the other threads, it wasn't our intention to borrow credibility or dilute the term. Rather we're big fans of Nassim Taleb's Black Swan theory, and to us founding a startup (and our first usecase in testing) both related to high kurtosis.
That said, I hear you that it's confusing when people need to distinguish between "kurtosis the statistical concept" and "Kurtosis the company"!
Hi! Founder here, and apologies if reposting content in other comments above is too much. I can give some context on the name, although of course ideally context from me wouldn’t be necessary if the name was easier to parse.
Our very first users were test engineers who used our tool to spin up test environments for E2E and integration tests, and we called it Kurtosis because we imagined them catching “tail” errors that were out of the expected norm for devs focused on only one component of the system. We imagined a tool that detects bugs happening in a “high Kurtosis” error environment.
We’re also big fans of the book “antifragile” by Taleb, about strategies in general for excelling in the face of volatility environments (can stretch that to kind of look like high “Kurtosis” environments)
The combination of those two things felt right when we started building - but I can see all the confusion it’s now causing here!
I see, thanks for explaining -- let me see if I understand: you are trying to control kurtosis of a system, to reduce the outliers/errors in the distribution of functionality of a distributed system?
(other founder here) Yep, you got it! This is particularly relevant in the testing usecase where we started: "can we do whole-system E2E testing, so you catch more outliers before you hit Prod?"
> I can see all the confusion it’s now causing here!
Peanuts from a serial entrepreneur in the gallery, having been a co-founder of a full stack digital agency that helped and watched 10^3 startups ramp during the dot com boom...
## TL;DR: If you're explaining, you've already lost. Consider changing to something you don't have to explain. ##
Pick a name you don't have to explain because it's so excruciatingly clear... or so totally meaningless you get to define it. Consider it a red flashing warning sign if you find yourself having to explain because the term you liked is pre-pigeonholed as something else.
The comments here are valid, you and the team are hearing, then saying ‘good point but here's all this background’ -- means you market tested the name, and found out.
Sooner is always better than later to fix market confusion. Your footprint to fix will never be smaller than it is today (unless someday marketing doesn't matter any more). Plus in the "awareness" stage of marketing you can't fix by explaining. Your first chances are "engagement" or "onboarding" and by then you've already lost revenue to the confusion.
As a both devops and ML professional at my job (it's a small company), I viscerally cringe at the same kurtosis for this company (which I just learned about). There could be some kind of latent jealously/projection causing that cringe, but here's my rationale (could be very specific to my career):
* Devops folks don't seem to tend to like math and often got there by practicing, "computers, IT, having fun hooking things together and getting them running."
* Data science folks don't tend to like devops and prefer to bash around on a jupyter notebook that's already given to them and then maybe extract that python and see if it runs, but they tend to come from more of a science background and got into python as a hobby or incidentally. They do not like bashing around and getting things running.
So now this company is combining a math term that has a specific meaning to an ML ops space, which is going to cause confusion.
Different sets of data can have different kurtosis measures. Sets can be platykurtic (flat gaussian curve or high kurtosis) or leptokurtic (tall gaussian curve, low kurtosis).
Now this company is coming in and telling a bunch of devops people, "Kurtosis means helm but automatically migrate data too." So they are applying the idea of, "leptokurtic deployments," presumably with the metric being, variation between the code and data parameters on those servers. Data science people who are told about it from devops people are going to initially hear, "somehow dealing with cleaning the data, like an ETL pipeline, perhaps an Airflow with data cleaning tools built in or something."
It's very confusing and not helpful to customers, I hate it. There are going to be meetings where ML/Devops people are very confused.
Naming is hard though -- but I wish they would have gone with something like, "platypus" and just have a cute little platypus baby as the logo and say, "yeah we liked the word platykurtic because we like making things regular and platykurtic sounds like platypus."
Hi! Founder here…thanks for the feedback, deeply appreciate it. Especially the last bit about how hard naming is haha.
To give a bit of context on the name, our first set of use cases was all about test engineers using this tool to testbeds for end to end or large scale integration tests.
Since we are pretty mathy ourselves, we called it “Kurtosis” because we imagined the distribution of errors arising from service to service interactions to have a high Kurtosis - in the sense that there’s a lot of errors you wouldn’t “expect” to happen from a first principles understanding of each component. You’d have put them all together to see those, they’d be “far off the mean”. There’s also a lot of stuff about how we view our work, where we like exposing ourselves to outlier opportunities that we hadn’t previously imagined to produce results that would only happen in a “high Kurtosis results distribution”.
Now that being said, I definitely hear what you’re saying. It’s not obvious that’s where the name came from…and just because we were thinking that when we named it doesn’t mean it resonates with our users the same way!
That feedback came straight from my basal ganglia.
Though I'm guessing that was a pretty expensive domain name. So in lieu of changing it, on this issue I can be bought off.
But I will accept a bribe in the form of a medium sized T-Shirt to not make fun of you further. The T-Shirt must include an anthropomorphized gaussian curve in a math meme format and the curve-person must be clearly labeled as being name, "Kurt Osis."
Any Kurtosis logo must be either non-existent or super non-prominent so that I can at least pretend that it's a meme and then maybe tail into where it came from. A huge emblazoned Kurtosis logo on the back or front will be unacceptable (although Kurt Osis could have that logo on his or her or their shirt).
> * Devops folks don't seem to tend to like math and often got there by practicing, "computers, IT, having fun hooking things together and getting them running." * Data science folks don't tend to like devops and prefer to bash around on a jupyter notebook that's already given to them and then maybe extract that python and see if it runs, but they tend to come from more of a science background and got into python as a hobby or incidentally. They do not like bashing around and getting things running.
Everyone likes cool sounding terms though! Any such term will eventually end up being co-opted. We have isomorphic Javascript and all kinds of stuff like that.
Not saying it’s good or bad, it will just happen.
Are customers really going to be confusing a CI system vs a data statistic? It’s a bit like being confused about apple the fruit and an Apple iPhone. The confusion will clear up pretty quickly.
Just to spare anyone the time: When they say "reproducible" they mean "can be done again" and not "can be done again with a consistent result".
No lockfiles, no checksums, URLs that may disappear and change at any time strewn around everywhere. There is none of the many nowadays common mechanisms in place that would ensure reproducibility (as the term is used in other build systems like Bazel or Nix).
Hey hobofan, one of the founders here. You're very correct - we don't have lockfiles yet! It's on our roadmap, but we haven't built it yet because the current level of reproducibility has been enough for our users right now (who are mostly dev and test).
That said, if we're to accomplish our goal of being the single platform across dev, test, and prod, lockfiles are an absolute must (we've actually been contemplating whether we can leverage Nix or Bazel under the hood). The design puzzle we've been working on is, how to enable non-determinism and flexibility in dev (e.g. "I want to always use 'latest' on my local machine"), and complete rigidity in prod. I'd guess that we'll have fully reproducible builds available in the next 3 months :)
Every time I see one announced, I check a few things.
The first thing I check is the build language. Usually, that indicates to me whether or not the build system would target the same audience that I eventually will.
In this case, they chose Starlark.
Whew! We are not going to target the same audience.
30 comments
[ 3.1 ms ] story [ 68.0 ms ] threadIs there another meaning of kurtosis that is applicable to this product? Kurtosis is used to describe aspects of probability distributions' tails/flatness.
Is this a pun on "distributed" systems?
But I see from the comments it is decently confusing!
Although I see how the overloading of the term is pretty confusing here
I think it’s a way of borrowing the credibility attached to the term. But at the same time it dilutes the original meaning of the term and confuses people over time.
That said, I hear you that it's confusing when people need to distinguish between "kurtosis the statistical concept" and "Kurtosis the company"!
Our very first users were test engineers who used our tool to spin up test environments for E2E and integration tests, and we called it Kurtosis because we imagined them catching “tail” errors that were out of the expected norm for devs focused on only one component of the system. We imagined a tool that detects bugs happening in a “high Kurtosis” error environment.
We’re also big fans of the book “antifragile” by Taleb, about strategies in general for excelling in the face of volatility environments (can stretch that to kind of look like high “Kurtosis” environments)
The combination of those two things felt right when we started building - but I can see all the confusion it’s now causing here!
Peanuts from a serial entrepreneur in the gallery, having been a co-founder of a full stack digital agency that helped and watched 10^3 startups ramp during the dot com boom...
## TL;DR: If you're explaining, you've already lost. Consider changing to something you don't have to explain. ##
Pick a name you don't have to explain because it's so excruciatingly clear... or so totally meaningless you get to define it. Consider it a red flashing warning sign if you find yourself having to explain because the term you liked is pre-pigeonholed as something else.
The comments here are valid, you and the team are hearing, then saying ‘good point but here's all this background’ -- means you market tested the name, and found out.
Sooner is always better than later to fix market confusion. Your footprint to fix will never be smaller than it is today (unless someday marketing doesn't matter any more). Plus in the "awareness" stage of marketing you can't fix by explaining. Your first chances are "engagement" or "onboarding" and by then you've already lost revenue to the confusion.
* Devops folks don't seem to tend to like math and often got there by practicing, "computers, IT, having fun hooking things together and getting them running."
* Data science folks don't tend to like devops and prefer to bash around on a jupyter notebook that's already given to them and then maybe extract that python and see if it runs, but they tend to come from more of a science background and got into python as a hobby or incidentally. They do not like bashing around and getting things running.
So now this company is combining a math term that has a specific meaning to an ML ops space, which is going to cause confusion.
Different sets of data can have different kurtosis measures. Sets can be platykurtic (flat gaussian curve or high kurtosis) or leptokurtic (tall gaussian curve, low kurtosis).
Now this company is coming in and telling a bunch of devops people, "Kurtosis means helm but automatically migrate data too." So they are applying the idea of, "leptokurtic deployments," presumably with the metric being, variation between the code and data parameters on those servers. Data science people who are told about it from devops people are going to initially hear, "somehow dealing with cleaning the data, like an ETL pipeline, perhaps an Airflow with data cleaning tools built in or something."
It's very confusing and not helpful to customers, I hate it. There are going to be meetings where ML/Devops people are very confused.
Naming is hard though -- but I wish they would have gone with something like, "platypus" and just have a cute little platypus baby as the logo and say, "yeah we liked the word platykurtic because we like making things regular and platykurtic sounds like platypus."
To give a bit of context on the name, our first set of use cases was all about test engineers using this tool to testbeds for end to end or large scale integration tests.
Since we are pretty mathy ourselves, we called it “Kurtosis” because we imagined the distribution of errors arising from service to service interactions to have a high Kurtosis - in the sense that there’s a lot of errors you wouldn’t “expect” to happen from a first principles understanding of each component. You’d have put them all together to see those, they’d be “far off the mean”. There’s also a lot of stuff about how we view our work, where we like exposing ourselves to outlier opportunities that we hadn’t previously imagined to produce results that would only happen in a “high Kurtosis results distribution”.
Now that being said, I definitely hear what you’re saying. It’s not obvious that’s where the name came from…and just because we were thinking that when we named it doesn’t mean it resonates with our users the same way!
Though I'm guessing that was a pretty expensive domain name. So in lieu of changing it, on this issue I can be bought off.
But I will accept a bribe in the form of a medium sized T-Shirt to not make fun of you further. The T-Shirt must include an anthropomorphized gaussian curve in a math meme format and the curve-person must be clearly labeled as being name, "Kurt Osis."
Any Kurtosis logo must be either non-existent or super non-prominent so that I can at least pretend that it's a meme and then maybe tail into where it came from. A huge emblazoned Kurtosis logo on the back or front will be unacceptable (although Kurt Osis could have that logo on his or her or their shirt).
Everyone likes cool sounding terms though! Any such term will eventually end up being co-opted. We have isomorphic Javascript and all kinds of stuff like that.
Not saying it’s good or bad, it will just happen.
Are customers really going to be confusing a CI system vs a data statistic? It’s a bit like being confused about apple the fruit and an Apple iPhone. The confusion will clear up pretty quickly.
No lockfiles, no checksums, URLs that may disappear and change at any time strewn around everywhere. There is none of the many nowadays common mechanisms in place that would ensure reproducibility (as the term is used in other build systems like Bazel or Nix).
That said, if we're to accomplish our goal of being the single platform across dev, test, and prod, lockfiles are an absolute must (we've actually been contemplating whether we can leverage Nix or Bazel under the hood). The design puzzle we've been working on is, how to enable non-determinism and flexibility in dev (e.g. "I want to always use 'latest' on my local machine"), and complete rigidity in prod. I'd guess that we'll have fully reproducible builds available in the next 3 months :)
Every time I see one announced, I check a few things.
The first thing I check is the build language. Usually, that indicates to me whether or not the build system would target the same audience that I eventually will.
In this case, they chose Starlark.
Whew! We are not going to target the same audience.