What are the advantages of separating 'result' from 'status'

Question

Let's say you have some automated processes that generally go through the following states; scheduled - initiated - validating - executing - completed

On top of that these processes can prematurely end because of an error or explicit user cancellation.

My first impulse is to simply add error and cancelled to the list of possible status values, but I was wondering about the (conceptual) advantages of separating result from status (even though it seems to me that one might argue that error and cancelled are also simply different states than the completed state).

Answer 1

The state you assign to your processes should reflect what your program (or the users, if you are just visualizing states) are going to do with this information. So do you have the requirement to evaluate / show the state of your processes as long as they are running and showing no error? Then separate result from status. If you just need the status when a process has ended, then don't separate.

You should not model anything just for the sake of modeling. Better check your requirements. And if you are unsure about what you might need later, choose the smallest, most simple solution for the requirements you know for sure. If you are just "guessing", in 90% of all cases you will guess wrong, so you will have to change your model later anyway.

Answer 2

but I was wondering about the (conceptual) advantages of separating result from status (even though it seems to me that one might argue that error and cancelled are also simply different states than the completed state).

There is a great advantage in detailing progress and identifying failiure points (within reasonable limits) as in your case. I think the confusion stems from the terms 'status' and 'state' - We must qualify those terms. So for example, "Task Status", even that is not very precise, so we may want to use "Task Execution Status", however this is wrong because you already have an execute step. We may use the name "Task Processing Status" and the values of: "initiated - validating - executing - completed" make perfect sense. Indeed we could add 'Cancelled' to the list. However, 'Error' does not answer a question like: What is the Task Processing Status very well. It looks like 'Error' is a sub-status of Completed. So what do we do? We could rename Completed to be Completed OK and then we could add Completed With Error to the list. So the final list of the Task Processing Status values are:

• Initiated,

• Validated,

• Executing,

• Cancelled,

• Completed OK,

• Completed With Error

Edit: now the above list still requires some work. The first 4 items don't have the word 'OK' in them. So if it better be there to match the "Completed OK" state. The other thing is that the first 4 items don't have a "with error" - What doe that mean? What happens when "Executing" abnormally ends - Does that call for a new state of "Executed with Error"? At this point, more input and analysis may be required.