I think the article lacks nuance. Of course, asking devs to guess at how long something will take at the very beginning of a project is not going to be very acc

I think the article lacks nuance. Of course, asking devs to guess at how long something will take at the very beginning of a project is not going to be very accurate. That doesn't mean that sticking to a schedule has no value. Basically, the project plan has to allow for some scope cutting along the way. There will always be a few false assumptions that are discovered only after the project is well underway, and the only way to manage that is minimize the surface area of any given dependency. The responsibility of delivering a project on time belongs to the manager (which for the purposes of this comment can belong to an IC if she or he decides to think like a manager). For every milestone on the schedule, the manager should know all the risks for reaching the milestone and should have a plan for handling each eventuality. This type of planning goes hand in hand with protecting the team from distractions, preventing scope creep at all costs, and setting the goals of the project before it has even started. Software created with time constraints is higher quality and is more fun to make.