I kind of like the article take on how to handle emergent issues, but I don't like that it still sort of silos software development into two parts -- planned and unplanned.<p>I hate the term "unplanned" to describe this kind of work. By using a very narrow definition of "plan", for work "organized and scheduled in advance" but only within projects and roadmaps, it sort of works. A more informal usage of unplanned, though, suggests a kind of blindness to the reality of software development and maintenance.<p>The reality is that the effort in software development isn't easily divided into these streams. The article fails to address an important consequence of putting effort into fighting fires: the project plans and roadmaps of the affected teams <i>will</i> be disrupted. This is where the term "unplanned" really fails, because if the organization never takes into account the effort taken to address issues and emergencies, the plans are worse than having no plan at all.<p>On a different note, one place I consulted with had its planning and tracking tool (Jira-like Azure DevOps) directly feed into its accounting system, such that different types of work were bucketed into different amortization flows. Planned work was a capital expenditure (CapEx), while anything funneled into Unplanned became an operating expenditure (OpEx). Any accountant that knows the implications of CapEx vs. OpEx can see where this is going. This company had a <i>lot</i> of bugs and issues that were left unaddressed.