In our earlier work,^{9} we hypothesize a simple timed Markov model of a researcher developing a new application. It represents our assumption that the researcher begins by formulating a new algorithm for solving the problem of interest and then writes a program implementing the algorithm. Following that, the researcher enters a correctness–debugging loop, around which the process cycles until the program is deemed to be free of programming errors. Next is a performance–tuning loop, which cycles until the program has been tuned enough that it gets adequate performance for large problems to be run on an HPC system. This is the workflow shown in Figure 2. In this workflow:

- T
_{f}represents the time taken to formulate the new algorithmic approach. - T
_{p}is the time necessary to implement the new algorithm in a program. - T
_{c}is the compile time. - T
_{t}is the time necessary to run a test case during the debugging phase. - T
_{d}is the time the programmer takes to diagnose and correct the bug. - T
_{r}is the execution time for the performance tuning runs. This is the most obvious candidate

of a constant that should be replaced by a random variable. - T
_{o}is the time the programmer takes to identify the performance bottleneck and program an

intended improvement. - P
_{p}is the probability that debugging reveals a necessity to redesign the program. - P
_{d}is the probability that more debugging is necessary. - P
_{o}is the probability that more performance optimization is necessary. - q
_{p}, q_{d}, and q_{o}are 1 - P_{p}, 1 - P_{d}, and 1 - P_{o}, respectively.

This model can also be used to describe the workflow of graduate students programming homework in a parallel computing class. We instrumented their programs, collected workflow data and fit it to such a timed Markov model in our 2004 classroom experiment.^{9} While fitting the experimental data to the model, we discovered that in addition to the transitions described above, there were two more transitions. A programmer may introduce or discover a bug while attempting to optimize the program. As a result, there is a transition from the Run state to the Debug state. Sometimes, the last run may not be successful, perhaps because of a failed attempt to optimize. In such a case, an earlier correct run is treated as the final program – all the data we present is from programs that were eventually correct. Hence, there is another transition from Test to Finish. Figure 3 shows the result of our analysis of the 2004 classroom experiment.