I think context matters a LOT here. Knowing when to be pragmatic and quick vs thorough is the mark of an experienced engineer. The trick is knowing HOW to pick the right approach.
A key point is understanding the business (or personal) goal of the system.
Is this a mission-critical system that is core to how the company makes money? Then make sure its robust.
Are you a startup figuring out product-market fit? Then thorough and robust systems matter less. The goal is figuring out how to get users and customers, not stabilize.
Generally agree with this approach. We need to make sure that friction exists in our kids' lives.
I have a toddler, and screen time is something that is on top of my mind, Balancing the trade-offs of when to use it while also minimizing it as much as possible.
Something that made me really sick to the stomach was learning how Cocomelon was doing AB testing to make sure that children don't look away from the show[1]. In response to that, I default to showing my kids shows from the 90s that didn't use cuts, aggressive cuts, to keep attention going. Things like Sesame Street, Mr. Rogers Neighborhood, etc.
Heck, I remember trying out one Disney show focused on Minnie Mouse and barely allowed the show to run for three minutes after I realized that there were multiple cuts happening every three seconds.
I like this angle. I didn't read much of the article, but I do think this is a topic that people should consider, at least when it comes to estimating software projects. I don't think we really think enough about the monetary costs of our projects. When I raise the topic in my discussions, it really changes and focuses people, particularly when folks are advocating for tech debt projects that don't really have a return because they're not a focus for the company at this time. When we say that it's going to be a $60,000 project, it quickly becomes deprioritized in the conversation.
A key point is understanding the business (or personal) goal of the system.
Is this a mission-critical system that is core to how the company makes money? Then make sure its robust.
Are you a startup figuring out product-market fit? Then thorough and robust systems matter less. The goal is figuring out how to get users and customers, not stabilize.
I actually wrote more about this a while back: https://www.buildthestage.com/when-should-you-over-engineer-...