Oh absolutely. I can think of several situations where that wouldn't work well or at all, for example, a switch statement that sets up variables to be used in the rest of the function.
@btaf45 in my case, we as a team could have done that, because we didn't have management dictating how we did anything. It was our choice to do what worked for us, and it was a valuable tool for dealing with whatever got thrown at us.
Now I'm working in a different place that dictates Agile and Scrum to be done Their Way, on top of a project that's largely waterfall-like to begin with, and I'm starting to see why people say it doesn't work.
It works, BUT, only when you're using it as the right tool for the right job and not when management decide to misapply it as a hot new planning methodology.
@btaf45@mspencer712 The whole point of Scrum is to use the retrospective to stop doing what doesn't work and start doing what does.
At one point, when my team's workload changed to less-timeboxable work, we threw out the entire concept of sprints and just used kanban instead, and stayed like that for a year. We still did retrospectives on the old sprint cadence though.
RTOS are not going to become consumer operating systems, because there's too much value in selling it as a capability to enterprise customers (who are largely the consumers who REQUIRE a RTOS, rather than it merely being a convenience).