> It’s important to note that when the date is the most important thing, the body of work must be flexible, and vice versa. You shouldn’t have both constraints.

> It’s important to note that when the date is the most important thing, the body of work must be flexible, and vice versa. You shouldn’t have both constraints. This will help bring clarity to the value. The last product-ish app I did (internal to the company), either neither of those was a constraint, or they both were. I was taking an existing manual process backed by an Access app, and making a web version that would assist with some of the manual steps. There was no inherent cutoff date. There were multiple possible levels of functionality. But every $PERIOD that it wasn't usable was another that the user team remained overworked, and every level not written was more of the manual work not automated. It eventually dropped to WONTFIX levels of my to-do list at somewhere around 1/3 of the potential functionality implemented. But before that it was at the very top, and the "due date" was "help we're bleeping dying over here". . I don't think that really translates to the proposed viewpoint in the article.