Live data from Hacker News

Launch HN: Okay (YC W20) – Analytics for engineering teams

news.ycombinator.com

11–20 of 36 posts

Re: Launch HN: Okay (YC W20) – Analytics for engineering teams

#11

I love the idea of having metrics for things like "how long are people spending waiting on builds". You mention that you're trying to get data from existing tools rather than requiring self-reporting. What are you using to track time spent on local builds? I'm currently building a service to speed up both local and CI builds. I'd love to talk with you more; my email is in my profile.

For time spent on local builds, we expose a tracing-like API where you can tag the build id, start and end events, as well as connect it back to the right team. This custom event gets joined with everything else. I'll reach out to you on your email!

Re: Launch HN: Okay (YC W20) – Analytics for engineering teams

#12
Does this work with systems outside of the Microsoft/Google ecosystem (i.e. not github, not g suite/gcal)?

I'm interested, but it's unlikely that I'm going to be building teams on either of these platforms in the future, considering how easy these are to host internally now.

Re: Launch HN: Okay (YC W20) – Analytics for engineering teams

#13
post #5

Disclaimer: I'm a competitor of Okay along with others in the software development metrics space. I just want to comment on > We also learned that the discussion about engineering metrics always falls into a false dichotomy: don’t measure anything because engineering is creative work (it is!) or measure engineers in intrusive ways along meaningless dimensions like lines of code. I think with close to 50 years of doin…

The way to get engineers to adopt it is to demonstrate how it can be useful for them. Engineering quality of life can be derived from a lot of these metrics.

Take for example, XKCD 303: https://xkcd.com/303/. Engineers spend so much time waiting on compile, build, and deployment time. It is such a waste of time and resources. These are things that engineers tend to absorb resulting in engineers getting blamed for low velocity.

The other area is on call metrics. Healthy oncall metrics significantly increases engineering QOL.

Re: Launch HN: Okay (YC W20) – Analytics for engineering teams

#14
post #13
post #5

Disclaimer: I'm a competitor of Okay along with others in the software development metrics space. I just want to comment on > We also learned that the discussion about engineering metrics always falls into a false dichotomy: don’t measure anything because engineering is creative work (it is!) or measure engineers in intrusive ways along meaningless dimensions like lines of code. I think with close to 50 years of doin…

The way to get engineers to adopt it is to demonstrate how it can be useful for them. Engineering quality of life can be derived from a lot of these metrics. Take for example, XKCD 303: https://xkcd.com/303/ . Engineers spend so much time waiting on compile, build, and deployment time. It is such a waste of time and resources. These are things that engineers tend to absorb resulting in engineers getting blamed for lo…

> The way to get engineers to adopt it is to demonstrate how it can be useful for them

Agreed. My goal is produce a connected efforts graph that can accurately connect code with effort and time spent (meetings, code reviews, waiting for builds, etc.)

This is why I refer to this as business intelligence for the software development lifecycle. Insights come from data and you can't use traditional BI tools to analyze software development data. If you want to understand effort, you need to be able to slice and dice coding activity which GitHub and traditional BI tools can't do easily or at all.

Take the following for example, if you want to quickly understand the significance of three commits, you can do something like this:

https://public-001.gitsense.com/insights/github/repos?q=comm...

which will stitch together the commits in real-time for analysis. And this is what I ultimately mean by being able to slice and dice software development activity. And how I see thing is, BI for software development activity is both useful for developers and leaders.

Re: Launch HN: Okay (YC W20) – Analytics for engineering teams

#16
post #12

Does this work with systems outside of the Microsoft/Google ecosystem (i.e. not github, not g suite/gcal)? I'm interested, but it's unlikely that I'm going to be building teams on either of these platforms in the future, considering how easy these are to host internally now.

Currently we only support these ecosystems because most of our early customers are on these platforms. We do have a tracing-like API that you can use to send custom events, but that would require more integration work of course.

Re: Launch HN: Okay (YC W20) – Analytics for engineering teams

#17
post #15

What is the point of having a webpage called "Pricing", which has practically no information about pricing? (Rhetorical question)

Often the “pricing” page is the first page potential customers check prior to evaluating the product. Without one the customer journey generally gets disrupted.

Re: Launch HN: Okay (YC W20) – Analytics for engineering teams

#18
post #15

What is the point of having a webpage called "Pricing", which has practically no information about pricing? (Rhetorical question)

Often the “pricing” page is the first page potential customers check prior to evaluating the product. Without one the customer journey generally gets disrupted.

Sure. And having absolutely no relevant info on that page is a great way to certainly disrupt a potential customer's journey one step later. :-)

Re: Launch HN: Okay (YC W20) – Analytics for engineering teams

#19
post #18

Earlier quoted context omitted.

Often the “pricing” page is the first page potential customers check prior to evaluating the product. Without one the customer journey generally gets disrupted.

Sure. And having absolutely no relevant info on that page is a great way to certainly disrupt a potential customer's journey one step later. :-)

It's a filter in the sales funnel, often intentionally. "Contact us for pricing" tells everyone what they need to know – either you have a big budget and are not price sensitive, or you're self service and this product isn't for you.

Pricing is hard, it makes total sense to just not publish prices early on.

Re: Launch HN: Okay (YC W20) – Analytics for engineering teams

#20
post #11

I love the idea of having metrics for things like "how long are people spending waiting on builds". You mention that you're trying to get data from existing tools rather than requiring self-reporting. What are you using to track time spent on local builds? I'm currently building a service to speed up both local and CI builds. I'd love to talk with you more; my email is in my profile.

For time spent on local builds, we expose a tracing-like API where you can tag the build id, start and end events, as well as connect it back to the right team. This custom event gets joined with everything else. I'll reach out to you on your email!

This is super cool. We know way more about Docker than we should now, but it seems like you could instrument local Docker for some teams.
Post reply on HN