I really appreciate the depth and explanation in this article. In my many years in the industry, I have yet to see such rigor coming from task maintenance as is

I really appreciate the depth and explanation in this article. In my many years in the industry, I have yet to see such rigor coming from task maintenance as is displayed by the author. For starters, tasks require deep knowledge of how something will be done. In our industry, a lot of the work is discovered while executing some other work. What you get are tasks being created while other tasks are being worked on. This back flow of work would also have to be captured as part of the process with the additional metric of how well we plan our work and hold people accountable to that result. Since software engineering is part art, industrial processes are inadequate in capturing the productivity of software engineering work. Instead, a lot of focus is on the ability to estimate overall completion dates, adherence to that schedule (often requiring evaluation of compromise and reduction of scope), and the impact of that work (both positive in a measurable way, and negative in code debt and incidents). What's unfortunate is that a lot of infrastructure work focuses on improving engineering cadence. Without the process described in this article, measuring productivity gains from introducing a new tool or technology can at best be measured using adjacent metrics (e.g. compile time, deploy time). I hope one day we can reach the level of engineering rigor prior to execution described in this article, but I still believe that the nature of software engineering is that there will be a non-trivial amount of immeasurable effort that doesn't fit the model described in the article.