fredsters_s

You could easily spin up a forum where power users help each other

tell me you've never run anything without telling me you've never run anything...

it is very funny that most of the (presumably germans) in the comments are saying "it's not that bad and it's fine because you chose a complicated LLC structure"

you might enjoy cities: skylines

Super awesome, love the vision, exciting to try something in this space, and agreed with your core observations and conclusions. My only criticism is that the interior / package needs to look way cooler to tempt people across. Working with a decent industrial design firm and making some sexy renders would go a long way!

the twitter convo is pretty good, but AMA here if you're interested!

moving from offense to defense... tends to be a bad sign

been using the beta - really love it

yes :)

Oh good catch Todd, sorry about that - updated.

And totally agreed, both products take a slightly different approach and have different strengths and weaknesses, try them both and see which is a better fit!

it kinda is :) - 10 years in, we're just getting started!

the other major difference is the design principles: our core belief is that everyone owns quality, and so we build for the 'no code' user as well. It's a really hard bar to hit, but I think we've done a good job so far - to use reflect you need to be far more technical. 1/3 of our daily users are PMs.

Nowhere do we say that the entire product organization - devs, designers, PMs - should not care about quality. It's a question of ownership and focus.

First off, we totally agree on this: "true product Quality is dependent upon an endemic cultural philosophy of an organization."

What we're asking you to consider is how much of that is because the tooling is shutting out the roles who are naturally incentivized to care about product quality?

I think your broader thesis, while amusing, is ignoring some of the biggest and most valuable brands ever created... Apple, Rolex, Mercedes...

We have a free trial - you should try it instead of criticizing theory, I would love to get your feedback on the actual product, here or directly (I'm fred@rainforestqa.com).

Regarding DOM interaction, you're missing the point. All automation that tests the front end code, regardless of how it attaches, is using a path that is different from your end user. The end user interacts with the application visually. That's why we test visually. A decrease in code-based brittleness is just a nice side effect. And as you note, this is a very high-level post outlining one key idea about quality ownership. You may be interested in this, which is one of our front end folks talking about why we believe testing visually is superior: https://www.rainforestqa.com/blog/the-downfall-of-dom-and-th...

We have been selling a QA solution for almost 10 years. In that time we've seen thousands of setups and directly worked with hundreds of teams. Your claim "weaknesses of automated test frameworks [...] are compensated for quite easily and routinely" is, quite simply, not true for the majority of engineering teams - few QA leaders, including proponents of Cypress, would agree with you.

to say developers should not be interest or responsible for quality is most certainly a cop out

Read the piece - it says no such thing. It's talking about 'ownership', which is distinct from participation and most certainly from interest.

I totally see your point here - it's frustrating that how I presented it undermined the impact of the core point, which is that siloed ownership of quality is an anti-pattern, and an anti-pattern which is often a response to the limitations and design principles of quality tooling.

We are to my knowledge the only product built for this kind of cross-functional ownership, that's why I don't recommend other products.

While I agree the post is too marketing-y - to be honest I didn't expect it to appeal so much to the HN audience - it was written in good faith. We built the product because after 7 years of building a product for one of those silos, we became convinced that the only long-term durable solution was to empower everyone to own quality. Clearly I need to figure out how to strike the balance that you outline in your last sentence, which was the goal!

[author here] You are absolutely right: the optimal setup is a cross-functional team of domain experts collaborating on solving the customer's problem. The article is meant to point out that siloing QA to either just dev or just QA is an anti-pattern that is unstable and will not work, long term, without significant pain.

I think the challenge is that, while we agree on the optimal setup, it's almost never done like this. There's lots of reasons why, but the main one (imo) is organizational scaling. The logic of scaling teams tends towards specialization, especially because developer time is extremely expensive.

There are many ways to address the problem of QA. From our perspective, if they don't broaden the ownership of QA from just developers or just QA engineers (which is where all the current products are targeted), they will exacerbate this specialization problem.

I think the ideal team setup is one you allude to: a cross-functional team with experts from each domain collaborating together. My intent was not to say that can't happen - but that it typically doesn't, because of specialization and organizational politics. The vast majority of software teams have a siloed QA team. Why? That's for another thread :)

[author here] Both are solid points!

Regarding the incentive structure, I think you're right - there's no way to eliminate the friction that comes from competing incentives. Our experience has been that empowering the product organization to make that tradeoff themselves leads to the optimal outcome for the business. The goal isn't to eliminate the tradeoff between speed and quality, but surface it, and put it in the hands of the people who are the business decision makers, which tends to be product.

Re test data - we had seen this bottleneck with our previous product, which was purely about crowd testing. What we've seen since we shipped no code automation is that much of the data seeding by less mature teams can be done through the tests themselves. This is suboptimal, but with automation so cheap and fast, it works. Then over time the engineering team can seed the states that are most often created through the tests.

this has been our experience as well - sadly, however, most (all?) teams specialize and silo as they scale, and so you don't tend to see this setup beyond the very early stage

There are obviously substantive issues with the messaging - however, the piece reads like a hand-wavey bad-faith attempt at creating controversy for internet hype, for an upcoming book.

Silicon Valley is literally built on 'paying it forward'. Giving advice to others for free because that's how you got to where you are today. That's what the mentors here are doing. To feign ignorance of that, and then to wrap it up in a half-baked "bUt ItS Vc EvIL" is pretty transparent.

I don't disagree, but not sure how you can make that claim given that you didn't ever experience your idealized version (which never existed after the 70s)

it's too bad really, the long-haul price competition they created on their routes was fantastic

on further investigation this is not true - they applied with a bitcoin wallet. Thanks for the fact check!

HN used to rewrite clickbait headlines...

YC once tried an experiment of funding seemingly good founders with no ideas. I think every company in this no-idea track failed

...coinbase was a 'no idea' startup

Jeff works at Rainforest QA (we're YCS12) doing QA stuff for our customers. He's happy to answer any beef you have with his hot takes right here :)

(I wrote that answer)

A few principles that may be useful:

- have a regular cadence of communicating, usually monthly, usually he last day of the month

- have a standard format and stick to it

- numbers are better than words

- preview the updates where you uncover scary stuff over the phone / in person before sending an update

- always include an ask

Much less. Not just localized salaries (GH didn't used to do this, they may do now) which are always cheaper than SF, but for employees outside of the US no benefits cost, health insurance etc.

It's opportunistic investment from investors who predict continued growth.

The hook for the founders? Who knows. My guesses:

- assumption that eventually the enterprise play will win the majority of the $ in the market

- that there is possibly a winner-takes-all dynamic in the market, given the strong ecosystem benefits

Also, it's very expensive to sell top-down to enterprises. In SaaS your cost of sale is up-front (sales salaries, commissions, acquiring the customer etc) whereas the payout is typically over time. Even if the contracts are mostly paid up front, you still have to build the enterprise sales team and ramp the reps, which can take around 6 months. So it's possible that the logical premise "pumping all this money into firms that clearly don't need such vast amounts of it" may be incorrect if enterprise sales success is required for long term success and they don't have the cash to 'go enterprise'.

Will be fascinating to see how this market plays out. My money is on Sid.