Re:Japan's Rail Workers Pointing at Things (2017)
by carlmr on Monday January 21, 2019 @09:26AM
(#18960538)
While I love XKCD 1205 simplifies things too much. You have to account for human psychology.
Small times doesn't mean small impact on developer time.
1. Routine makes you much more likely to make errors because you're not fully focused. This error could feed into the next process step which is maybe longer, thus costing you disproportionate amounts of time if it fails.
2. If there are wait times in these short tasks (say 30 seconds to 30 minutes) these can have an inordinate effect on developer time wasted.
Say you have a "30 second task" you do a handful of times a day. You have to do something, then wait a bit, then do something else. If you're not a robot you will not like watching for the time it takes to complete. So you might switch to HN or whatever else you were doing. What happens after the task completes?
* You could have lost your state of flow (very likely) => that's another 15-20 minutes to get back into it.
* You might forget to context switch back. Boom 30 minutes have gone by. Oh it's lunch time now. I'll do that after. Then you come back, and forgot about it again. 2h have gone by in your 30 second task, and it's still not done.
3. The problem could be that you don't do the task often enough. Maybe it would help quality if the task was done every few seconds. If it's arduous or takes some time, you're much less likely to do it as often. The graph in 1205 assumes that the number of times the task is done is not related to the speed of execution or that it is a manual task. I don't think that's true. An extreme example of this would be my previous workplace. Build times were 5h, you needed to execute two steps to trigger a build. One step after the other completed (roughly 15 min).
People would waste a lot of time on finding errors that a compiler could find right away, because compiling took half a day and wasn't something you just wanted to trigger.
Small times doesn't mean small impact on developer time.
1. Routine makes you much more likely to make errors because you're not fully focused. This error could feed into the next process step which is maybe longer, thus costing you disproportionate amounts of time if it fails.
2. If there are wait times in these short tasks (say 30 seconds to 30 minutes) these can have an inordinate effect on developer time wasted.
Say you have a "30 second task" you do a handful of times a day. You have to do something, then wait a bit, then do something else. If you're not a robot you will not like watching for the time it takes to complete. So you might switch to HN or whatever else you were doing. What happens after the task completes?
* You could have lost your state of flow (very likely) => that's another 15-20 minutes to get back into it.
* You might forget to context switch back. Boom 30 minutes have gone by. Oh it's lunch time now. I'll do that after. Then you come back, and forgot about it again. 2h have gone by in your 30 second task, and it's still not done.
3. The problem could be that you don't do the task often enough. Maybe it would help quality if the task was done every few seconds. If it's arduous or takes some time, you're much less likely to do it as often. The graph in 1205 assumes that the number of times the task is done is not related to the speed of execution or that it is a manual task. I don't think that's true. An extreme example of this would be my previous workplace. Build times were 5h, you needed to execute two steps to trigger a build. One step after the other completed (roughly 15 min).
People would waste a lot of time on finding errors that a compiler could find right away, because compiling took half a day and wasn't something you just wanted to trigger.