Scheduling Pitfalls

I have been thinking about time again. More in terms of programming practices and less as in technical scheduling. This is just a point I try to remember when working on scheduling related problems. That being said: engineering reality often forces you make tradeoffs of course.

Moments slip by

In logical time we are starting from identity: We can tell points in time (also called moments) apart from another by them being distinct. M1 has an unique identity and M2 has an unique identity. These moments are different from each other. This ontology is not just philosophically relevant but gives us great power to create machines to perform work at certain moments. I would argue that logical moments are also persistent in state. A crontab file is not going to change unless you change it. Logical time is always discrete but two moments might have a relationship to each other.

Chronological time is a lot more analog, dynamic and “fuzzy”. A moment in chronological time is an observation of a stream. A sample if you will of a continuous function. The stream is continuous but the observer is discrete.

I should remember: A lot of problems arise when dealing with chronological time from logical time and vice versa.

Category error: Time as approximated state

Time in a sequential procedure is a most always the worst indicator for a state change.

put pasta water on stove -> wait 5 minutes -> put in pasta

Obviously the pasta water might not be boiling after 5 minutes(stove might be turned too low or even off). The correct way would be to verify the state by looking at data or features. The water is bubbling and steaming? Or a thermometer shows actual degrees? We often combine time and state checking in polling to wait and check. But a blind timer is almost always the wrong answer. Timeouts are a special term for blind timers. State relations triggered by timeouts depend on chronological time and can be helpful as a last resort. But think about this: Would you add a “just-in-case” clause to a while loop just because you are afraid about it not terminating?

Don’t use time as a scapegoat for unsharp thinking or being lazy: If the e2e test runs more than 5 minutes it might be safe to assume “something” has timed out and therefor we can time out the whole test? No, I should at least make sure that the systems and environment is handled.