[nerdface]

We often forget that if something took one hundred attempts, then we've learned ninety-nine ways something won't work. Those failed attempts do go somewhere in the progress of project, they're just not apparent to the observer.

[dcow]

And while this happens at the company scale (1/100 startups succeed) I’m wondering why it doesn't happen at the software scale. Why aren’t product teams trying out many ways to meet users needs, scrapping, iterating, prototyping, and then finally building? Most of the time it’s: I want this feature, build!

[Someone]

Because perfect is the enemy of good. (https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good)

And it’s not just that perfection takes longer to achieve; the estimate of how long it will take to reach it will be less reliable than that of multiple smaller steps.

Because of that, I think one can even argue good is the enemy of good enough.

As a simple example, a product is more likely to see the addition of, first, one report, than a second, a third, etc, than the addition of a good report builder.

For the former, each step is relatively simple, and first value will be delivered sooner. For the latter, you’ll have to answer questions about what the full range of to be supported reports would look like.

Even if you, up-front, know you’ll need to support tens of different kinds of report, it may be hard to argue that you need a report builder even if that seems to be the better choice to get to the end result.

If you do end up with a report builder, it likely will be one designed by and written for developers. As an example, look at headers and footers in Excel, where, I think to this day, you have to type && to get a single &: https://www.journalofaccountancy.com/issues/2018/sep/excel-h....

[jdvh]

I suspect this might be why most open source software struggles to reach the quality of commercial products. If it takes 10 attempts to get the major design questions right a company will either get there eventually or get outcompeted. Open source projects typically grow out of somebody scratching their own itch, and that doesn’t involve the scrapping and iterating necessary to make a product that fits many users’ needs.

[daniel_iversen]

Asana does (and Dropbox did) do a bunch of A/B testing all the time, usually with smaller features, to determine what works best, and will quite often evolve on the existing product and remove features they think they can do different or better. But of course one of the limiting factors is you can’t be too disruptive to your users (that’s why A/B testing is the slightly more gentle approach)

[_carbyau_]

Reminds me of a quote regarding magic tricks, paraphrased: A magic trick is a lot of hard work followed by a dazzling reveal.