Turning The Crank

I have a book on digital circuit design that refers to the boring part of the work as "turning the crank." (I think it's an earlier edition of John F. Wakerly's Digital Design: Principles and Practices

ISBN 0130898961

But everything after this point is me talking, not that book.

It's a metaphor that has some basis in history. Originally, humans had to turn the cranks that made things work, but then we figured out ways to get water to do it, or wind, or animals, or slaves (bad idea), or steam engines, or gasoline, or nuclear power.

Naturally, the goal of ComputerProgramming is to figure out a way to get the computer to turn your intellectual cranks for you. Naturally, ever since CharlesBabbage got bored doing calculations one day, a good programmer would expect that anything boring can, in principle, be automated.

Figuring out how to do it is the hard part, though. Sometimes it just seems easier to put your hands on the handle and turn the crank yourself -- especially when it only needs a few dozen turns anyway. When it becomes intolerable, only then do you begin to think of automation.

Is that intellectual laziness? Perhaps. But it's also a recognition of the fact that there is a cost (not necessarily just money) in setting up automation in the first place, even with a computer, even though, once it is set up, it runs almost for free. When the task you're automating is less expensive to do manually than the automation start-up cost, then hey, you do the work yourself. Even if it makes you cranky. -- EdwardKiser

Perhaps the crankiness of the problem is best expressed in the 3 numbers of ComputerScience : 0,1,n - 0 times = no problem, 1 time = manually, n times = automate that puppy! --PeteHardie

Right! I have sometimes said... "Twice is a pattern." (But I'm afraid that I don't always follow through on that philosophy. ;-) -- JeffGrigg

If something is done rarely, it is very easy to fool yourself into thinking that there is no need to take the time to automate it, even though you would eventually save more time than you spent as a result. To a certified procrastinator like myself, "Do <large> work now, or do smaller work multiple times in the future" is not a clear-cut decision.

One of the XP paradigms - "If it's difficult, do it more often" applies here. You turn the crank so often that it is no longer justifiable to procrastinate over automation.

The number can be more than two! Suppose something takes five minutes for you to do, but it would take you twelve hours to write the program that would do it for you. Obviously, it becomes more economical to write the program only if you know you have to do this thing more than 144 times. And usually you will want a greater margin than that; there may be some error in your 12-hour estimate of programming time, and it may be less risky to do the task 150 times, even though you would expect to save 30 minutes by automating it. -- EdwardKiser [Sun Apr 8 2001, 9:00 AM UTC]

Yes, but on the other hand, learning how to automate something teaches you more about the process of automation in general, so the next time you have to automate something you might do it more quickly. Turning the crank 150 times will probably teach you nothing.

Perhaps a more important point is that you may not have a clue how many times you are going to repeat a procedure. A possible rule of thumb in that case is to turn the crank till you've done the same amount of work as you expect it to take to automate the task. The next time you need to turn the crank, automate. I've had this kind of a rule in mind in trying to to work out how much time a just in time compiler should spend on optimizing a procedure.

: Sometimes, too, your boss gets used to the five-minute turnaround time, and is unwilling to accept a twelve-hour automation delay even if it is followed by clearing the backlog in 144 microseconds and then a one-microsecond turnaround time for all future requests.

Suppose something takes five minutes for you to do, but it would take you twelve hours to write the program that would do it for you

And how long does it take someone else to figure out what needs to be done? Automation embodies the intellectual property that otherwise resides in your head. Another advantage comes from separation of subject matter: the process can become data-driven.

Automated systems should pass the BusTest more easily than having one person who knows how to turn the crank.

This discussion corresponds to the first of LarryWall's great virtues of programming: Laziness. (The other two are Impatience and Hubris.) If I understand LarryWall correctly, failing to automate is a fine example of FalseLaziness - making more work under the delusion of getting it done faster.