8 ms·
> this article claims we tend to continue putting in the effort well past that point. it's because people have the irrational belief that their thinking and re
by chii 4y ago
> this article claims we tend to continue putting in the effort well past that point.
it's because people have the irrational belief that their thinking and reasoning more about a problem/decision makes their outcome better.
I think the common symptom found in software is design analysis paralysis. A software team end up using tonnes of time fretting about design choices (often as a committee), rather than just use that time to implement one of the designs. The (ir)rational idea that by reasoning about the design up-front, one saves the (potential) time lost in reimplementing a different design in the future!!
- alexanderdmitri 4y ago> it's because people have the irrational belief that their thinking and reasoning more about a problem/decision makes their outcome better. i'm not sure this is correct. i bet it often comes down to whether we've found an [emotionally] satisfying answer/outcome.
- galaxyLogic 4y agoDefinitely trying out different alternative designs is a good idea. But it has its cost as well. But you are right it is usually better to try out something than just ponder all the possibilities.
- Pelam 4y agoThis! Often (actually almost always) time it self is valuable for multiple reasons. Spending precious time in the "meeting room" instead of progressing towards (almost any) implementation can decrease the overall value and increase the risks. Also some people strongly prefer action over deliberation, especially by a committee so there is also a psychological cost to the team to consider. With software and a capable team, there can still be an illusion that decisions are cast in stone and can't be changed later, while the opposite is true. Implementing a solution that is almost there and then making corrections can be both more satisfying and lead to very good results. This of course requires the psychological freedom an flexibility to quickly acknowledge errors in thinking and design and not holding on to "the plan" too tightly.
- creakingstairs 4y agoI’ve argued for just building POC approach at times and worked out great sometimes. I found the issue was usually with management. Many have been extremely reluctant to throwing away code. Even though writing POC and re-doing everything will take the same time as planning for ages and doing it once.
- navane 4y agoProof Of Concept.
- nly 4y agoIt can be worth agonizing over the decisions early on while the system is simple and easy to change. Later on it's often not logistically, politically or socially justifiable to go back and fix or improve an original bad design decision and re-base and retest everything built on it. The result is engineers sat around muttering "I told you so" to themselves and wasting weeks debugging and hacking around bugs.
- duckmysick 4y agoSure. Now we need to know when it can be worth. If we do it all the time we're back to the starting point of this discussion.
- pydry 4y agoI find that the agonizing rarely bears as much fruit as doing. In some cases we've deployed, found horrible problems that were completely unexpected and switched course. Additional time spent agonizing would just have delayed getting us to the point where we learned those things. The critical information we needed to make that decision wasnt going to reveal itself with additional introspection. This isnt to day when a dev waves a big red flag in the beginning you should ignore them, though (ever). But, I find that waving that red flag doesnt ever inhibit delivery speed whereas multiple people agonizing over decisions where the information to determine the "right" one usually does.