3 ms·

I read most of the print version of this (which is very nice and I can recommend). One thing that really sticks out about this is just how much work in such a p

by bschne 4y ago

I read most of the print version of this (which is very nice and I can recommend). One thing that really sticks out about this is just how much work in such a project ends up going nowhere — you record something, you try using it weeks later, you realize it's useless, you do it again differently/better, lather, rinse, repeat. I'd somehow forgotten about this and started feeling kind of bad whenever I was working on something creative-ish (using it very broadly here) and didn't know exactly where each step would lead me. This sort of firsthand account of large projects goes a great way in reminding you that that's just part of the process.

nerdface 4y ago
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 4y ago
  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 4y ago
    Because perfect is the enemy of good. (https://en.wikipedia.org/wiki/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-headers-ampersand.html https://www.journalofaccountancy.com/issues/2018/sep/excel-h....
  - jdvh 4y ago
    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 4y ago
    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_ 4y ago
  Reminds me of a quote regarding magic tricks, paraphrased: A magic trick is a lot of hard work followed by a dazzling reveal.
hbn 4y ago
I also bought a print copy of this a while back from Stripe Press, along with a few other books. Haven't gotten around to reading them yet (I've been bad for reading lately) but gosh are they beautiful-looking books. They taunt me from the shelf every day.

by bschne 4y ago

nerdface 4y ago

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 4y ago
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 4y ago
  Because perfect is the enemy of good. (https://en.wikipedia.org/wiki/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-headers-ampersand.html https://www.journalofaccountancy.com/issues/2018/sep/excel-h....
- jdvh 4y ago
  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 4y ago
  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_ 4y ago
Reminds me of a quote regarding magic tricks, paraphrased: A magic trick is a lot of hard work followed by a dazzling reveal.

hbn 4y ago

I also bought a print copy of this a while back from Stripe Press, along with a few other books. Haven't gotten around to reading them yet (I've been bad for reading lately) but gosh are they beautiful-looking books. They taunt me from the shelf every day.