It would be useful if the web-site had a real case-study where they show all the features in action. Right now it looks like vaporware -- like one of those sites people put up to see if there is interest in an idea.

And perhaps stuff like this should have on-site capability for enterprises that don't use github, gitlab and such?

> It would be useful if the web-site had a real case-study where they show all the features in action. Right now it looks like vaporware -- like one of those sites people put up to see if there is interest in an idea.

True. We'll add better images and case-study to avoid the confusion.

> And perhaps stuff like this should have on-site capability for enterprises that don't use github, gitlab and such?

I'm assuming you are talking about GitHub Enterprise, Gitlab Self-Managed and Bitbucket Server. We currently have support for Bitbucket Server and working on the rest.

There's lots more issue tracking and code hosting systems (often run as independent parts, not all-in-ones) than those 3.

To avoid trademark fun, you may want to rebrand at some point.

A tech selection from Googling 'haystack'

https://www.haystack.tv/

https://project-haystack.org/

https://thehaystackapp.com/

http://haystackdata.com/

There is also https://expediadotcom.github.io/haystack/, an Open Tracing-compliant distributed tracing system.

There is also the Haystack group at MIT CSAIL, which has done some interesting stuff over the years:

http://haystack.csail.mit.edu/

Thanks for your comment. You might be correct.

What people on the internet are recommending is as long as the brand names would not be confusing it would be fine. The term "confusing" seems to be the tricky part. A trademark attorney would probably clarify it for us.

I find this website to be a fairly amusing example of how marketing co-opts real, generally easily expressible ideas to be an amalgamation of highly targeted jargon and pointed funnels for personal information collection.

Generally any well intentioned person who worked on an idea like this would be delighted to share what their product does specifically and clearly - unashamed screenshots of interesting visualizations (maybe half cooked), telling descriptions of specific numbers being crunched and their utility as predictive indicators of project success, verified with statistical certainty.

Sadly this kind of naive, honest approach is very regularly usurped by the machiavellian machinery of the professional art of convincing others to buy things, which is narrative focused and story driven with very little concrete substance.

Not blaming the author here, I understand the motivations at work and sympathize with them, but still sometimes find myself dumbfounded by the results.

Seems this is actually vaporware. No screenshots, no actual demo/application and signing up with emails leaves a "you'll receive an email soon" but no email arrives. Ebook requires email to download, and ebook ends up saying same stuff as on website already.

Sorry that you felt that way. We had a few issues with our sign up flow, but that should be fixed now.

The ebook has additional content such as

- Mitigate Bus Factor

- Protecting Deep Work

- Avoiding Engineer Burnout

and explains each problem in detail.

Thanks for "fixing" the issue. Now instead of saying "you'll receive an email soon", it now says "Due to increased demand, we've had to place you on a short waitlist. We'll be reaching out shortly with a link to get started."

Please tell people upfront what happens when they "sign up", as right now you're employing dark UX patterns just to collect emails.

Haystack aggregates activity in git to give engineering managers more visibility into how their team's work. We came up with the idea when we realized how difficult it is to answer a simple question: 'Is the team doing better than we were 6 months ago?'. We realized how hard it is to not only visualize trends on their team but get actionable insights into the biggest areas to improve. Whether it's spending too much time in code review, taking on too much concurrent work, or even getting bogged down with technical debt; we wanted a tool that can not only help to spot issues but also alert us so we can take action. Introducing Haystack.

Very curious now: how do you know what is "too much" time in code review?

Could you provide an example of actionable insight you provide when you have detected that a team is taking on too much concurrent work?

In the book you can check the sections Avoid Burnout: Work Overload and Overload Risk: Too Much Concurrent Work.

We get 6 months weekly average pull request throughput of each team. We call this the "Baseline Throghput". If a team has more (or less in some cases) pull requests open than the baseline, we consider that a "too many".

Too many Open Pull Requests can signal taking on too much work, scope creep, change in priorities and unexpected issues/bugs coming into the sprint. It’s good to keep an eye out of the number of Open Pull Requests since it’s a great indicator of the team’s current workload.

Absolutely agreed. None of that is particularly actionable, though. "Don't do the bad thing" is not actionable advice!

This isn't so much "show Hacker News" as "tease Hacker News".

Your web site shows me diddly squat. Do you actually _have_ a product? Where's the video walkthrough, or at the very least, some screen shots?

If your product were genuinely useful / insightful (which is very hard to do in this space) then we might buy it. For 400 seats. But it looks like vapourware to me right now. Come back when you actually have something to show the community.

Would love if the homepage showed actual screenshots of this product. It sounds interesting, but i'd like a sample of what is to come before signing up.

Great feedback. We'll be adding screenshots from the product rather than the book.

The pricing page is pretty confusing. Is the price per engineer per month? Whats the difference in engineers vs accounts?

Yes, it does seem to be per engineer. I think it's because it's tracking the git metrics on each engineer.

I'm pretty surprised that the price goes up per engineer as the team grows larger, especially as you're getting serious economies of scale -- all the math and stats is as easy to perform on 400 engineers as it is on 4, once you've got the system in place.

I would assume the "engineers vs accounts" is due to the output not being intended for the coders, but the managers. I.e. you only have accounts for the managers, but you price based on how large a team they are monitoring.

(This is just a guess, I have no connection to haystack)

You are correct. Accounts are basically number of managers that can access to the dashboard. Engineers tracked is the main business model.

Does the development team get the stats from this? I could see it empowering self organising teams.

If not it seems like a horrible product for engineers.

The product focuses on giving visibility by visualizing trends, identifing blockers and optimizing code reviews.

As long as the team has a visibility problem Haystack should be beneficial.

We have organizations prefering to use the stats more privately and only mention the necessary stats to engineers. We also have organization using our product in their daily standups. It depends on how the team choses to use it. We have seen both styles work well.

What's the minimum size team this tool would be useful for?

The problem starts to be big enough when the team has 8 software developers. Usually, the bigger the team, the bigger the problem.