4 ms·

> Why would you waste your time proving that something you wrote works, if you don't have product-market fit, What if your poor execution and untested software

> Why would you waste your time proving that something you wrote works, if you don't have product-market fit, What if your poor execution and untested software simply makes it appear you don't have product-market fit?

solatic 4y ago
You know, I really wish that a lack of automated tests translated to poor execution and short-term business failure, but having worked for multiple successful startups where that is not the case, sadly, I was proven wrong. In the face of evidence to the contrary, I changed my opinion. Testing needs to have business justification for it; "best practice" is not good enough. That means doing it when absolutely required for a feature's development, or tying it to revenue on the books.
- jrs235 4y ago
  100%! Best practice is to listen to your lawyer. Lawyers try to reduce all risk. Low risk, low reward. High risk, high reward. It's all about risk tolerance and management.
- vlovich123 4y ago
  I agree it might not relate to business failure but I’ll disagree on the impact to execution and I’m surprised that you’ve come to an alternate conclusion. Maybe I’m just a really shitty coder but I’ve yet to be able to write more than ~50 lines of non trivial code bug free. To be fair though, all the research on the topic I’ve read seems to bear out that that’s the typical quality. Honestly I’m normally skeptical of such lines of research but this has typically been work that’s replicated across companies with real world data sets so while not necessarily conclusive, directionally it seems correct. With tests I can verify that all the pieces will integrate correctly. I’ve found the cost of maintaining well written tests and code to be minimal vs the time spent on everything else (eg I’m just gluing complex components together instead instead of at the same time figuring out why the overall piece isn’t working). It’s also an easy spot to add small experiments of behavior when debugging (eg “is this component behaving correctly under these conditions”) whereas if you don’t have any tests or they’re all very high level, then the cost of debugging grows rapidly. For what it’s worth, I’ve worked on a number of complex r&d and engineering projects and have always observed the team moves more quickly with a good test suite, but I’ve also seen not good test suites that slow things down. Maybe it’s possible you’ve mostly observed bad test suites? I highly recommend Brett Victor’s talks about what development should look like. I think the main problem with tests is that they don’t let you mutate the runtime at will / see values inline / visualize what’s happening. I think that’s the next big step that would really clinch development to be much better.

solatic 4y ago

You know, I really wish that a lack of automated tests translated to poor execution and short-term business failure, but having worked for multiple successful startups where that is not the case, sadly, I was proven wrong. In the face of evidence to the contrary, I changed my opinion. Testing needs to have business justification for it; "best practice" is not good enough. That means doing it when absolutely required for a feature's development, or tying it to revenue on the books.

jrs235 4y ago
100%! Best practice is to listen to your lawyer. Lawyers try to reduce all risk. Low risk, low reward. High risk, high reward. It's all about risk tolerance and management.
vlovich123 4y ago
I agree it might not relate to business failure but I’ll disagree on the impact to execution and I’m surprised that you’ve come to an alternate conclusion. Maybe I’m just a really shitty coder but I’ve yet to be able to write more than ~50 lines of non trivial code bug free. To be fair though, all the research on the topic I’ve read seems to bear out that that’s the typical quality. Honestly I’m normally skeptical of such lines of research but this has typically been work that’s replicated across companies with real world data sets so while not necessarily conclusive, directionally it seems correct. With tests I can verify that all the pieces will integrate correctly. I’ve found the cost of maintaining well written tests and code to be minimal vs the time spent on everything else (eg I’m just gluing complex components together instead instead of at the same time figuring out why the overall piece isn’t working). It’s also an easy spot to add small experiments of behavior when debugging (eg “is this component behaving correctly under these conditions”) whereas if you don’t have any tests or they’re all very high level, then the cost of debugging grows rapidly. For what it’s worth, I’ve worked on a number of complex r&d and engineering projects and have always observed the team moves more quickly with a good test suite, but I’ve also seen not good test suites that slow things down. Maybe it’s possible you’ve mostly observed bad test suites? I highly recommend Brett Victor’s talks about what development should look like. I think the main problem with tests is that they don’t let you mutate the runtime at will / see values inline / visualize what’s happening. I think that’s the next big step that would really clinch development to be much better.