QA should not be forced into an engineering or automation track because the incentives are wrong. You end up with test code becoming the goal and then it usually rots due to most QA not having the experience to create a codebase that scales.
I don't think the industry today understands how to treat QA and I think that leads to a lot of assumptions that it's not useful.
I get excited because I went to school with one of Vaughan Jones' children and was (and still am) into math and was blown away when I understood that he was significant.
Years and years ago (pre-smart phone), I built a mobile map and navigation product. Labeling streets was one of the more interesting side quests and the solution I found took a similar approach of generating a large number of candidates, picking one solution, and iterating. It worked quite well in practice.
I can't speak to the accuracy, but I just integrated stripe's offering for our product (which involves banking). We were small enough for a while not to need it, but eventually the fraudsters find you.
If you don't take these measures, you will lose money to fraud. You may also lose your business because you aren't meeting your AML/anti-terror obligations. (I also just had to take my annual training course).
There are a bunch of mitigations, of which identity verification is just one, and all of them are lousy for our good customers. I wish the banking systems were better and we didn't need to do any of it.
I like the idea but I think it's going to be hard to put this particular genie back in the bottle. As an engineering leader, I prefer low fidelity designs early on, but practically no one else in my company wants that.
Designers have learned figma and it's the de facto tool for them; doing something else is risky for them.
Product leaders want high fidelity. They love the AI tools that let them produce high fidelity prototypes.
Some (but not all) engineers prefer it because it means less decision making for them.
I started in this industry before cloud was a thing. I did most of the things RDS does the hard way (except being able to dynamically increase memory on a running instance, that's magic to me). I do not want that responsibility, especially because I know how badly it turns out when it's one of a dozen (or dozens) of responsibilities asked of the team.
We're paying for pyx. Wouldn't have if we didn't enjoy enjoy uv and ruff.
It's definitely a narrow path for them to tread. Feels like the best case is something like Hashicorp, great until the founders don't want to do it anymore.
> Feels like the best case is something like Hashicorp
Wow, that's probably my go-to case of things going south, not "best case scenario". They sold to IBM, a famous graveyard for software, and on the way there changed from FOSS licensing to their own proprietary ones for software the community started to rely on.
You're not wrong, but a) most of the badness happened after the founders checked out and b) it's hard to find examples of developer tool companies doing better.
You however, are. Hashimoto didn't leave until December 2023, Hashicorp announced the license change August 10, 2023. Also way back in September 2021 they started having staffing issues and stopped accepting community contributions, and also made the questionable choice of going public that same year.
You might be on to something with point B, hard to find good examples of developer tool companies that don't eventually turn sour. However, there are countless examples of successful and still very useful developer tools out there, maybe slapping a company on it and sell a "pro" version isn't the way to go?
I actually would argue that Hashimoto "left" earlier. He "stepped down" from the executive team July 2021 and became an individual contributor then. He likely lost interest/power a long time before 2023.
Meh. The end of the company many of us admire was a combination of the founders giving up control to the usual villains and the venture business model failing for developer tools. I don't think the specific departure date matters very much; things started to degrade earlier.
As for "slapping a company on it", I agree, but also I don't think we've developed a viable alternative. Python has been limping along with one toolchain or another for my entire career (multiple decades) and it took Astral's very specific approach to create something better. It's fair to ask why they needed to be venture backed, but they clearly are and the lack of successful alternatives is telling.
I assume they want us to pay for their orchestration and also push customers back to using their compute so everything is stickier.
But nothing they've done in the last few years has demonstrated improvement in this area. As the person with both purchasing and final authority on these things in my org, it's hard to stomach.
QA should not be forced into an engineering or automation track because the incentives are wrong. You end up with test code becoming the goal and then it usually rots due to most QA not having the experience to create a codebase that scales.
I don't think the industry today understands how to treat QA and I think that leads to a lot of assumptions that it's not useful.
reply