Its Time to Decide

 
 
By Peter Coffee  |  Posted 2003-09-08 Email Print this article Print
 
 
 
 
 
 
 

Developing online algorithms brings many benefits.

Weve all worked with people who refuse to begin thinking about the answer to a question until they have all the facts; they want to be left alone while they think, rather than accepting new information as it arrives. But if I may paraphrase management guru Peter Drucker, its a terrible handicap to insist on waiting to make a decision until one has complete information. The most effective decision makers are those who can do the right thing, more often than not, despite confusing and inadequate data.

Its time to apply Druckers criterion to IT—not only to the decision making of IT managers but also to the algorithms that animate enterprise systems.

In everyday programming practice, most discussions of algorithm choice assume that the ingredients are ready: that the data set has been constructed and that its

time to start the machine. Today, though, our most interesting systems gather data from many locations via network links of varying speed and quality. So the greatest leverage in many critical tasks—for example, job scheduling and transaction risk assessment—may come from knowing when to stop waiting and get on with the job, even if the input is not yet all ready for processing.

Those who study this subject refer to these techniques as "online algorithms," meaning that they work with data coming in on a live connection rather than collecting all the data that they require and then ignoring everything else while they run.

There are many things wrong with the "go away, Im thinking" approach. For one thing, it deprives an interactive user of the chance to reconsider a question without first waiting for a no-longer-wanted answer. Ive had many users complain to me, for example, that when they mistype a database query or a Web URL, they waste far too much time waiting for the system to give up, when what theyd much rather do is interrupt with the input that they actually meant to provide. If theres one good reason for even the simplest applications to be multithreaded, its the value of having one thread always attending to user input, while other threads feed that input to the back end for distribution and processing.

Readers of Douglas Adams "Hitchhiker" novels will recognize an extreme case of "leave me alone" design in the fictional computer Deep Thought, which demanded an uninterrupted processing period of 7.5 million years to determine the ultimate answer to life, the universe and everything—only to announce that the result was "forty-two." It might have been nice to get intermediate results from the early stages of the analysis: If the computer had reported, after a million years or so, that the answer was "somewhere between 32 and 64," the people waiting for the final answer might have appreciated the resulting chance to rethink their approach.

When developers look at algorithms from an online perspective, it changes their thinking about what it means to refine their code. Normally, a developer looks at the time required from the moment data is ready to the time the final answer is produced. The online perspective starts measuring elapsed time earlier, when the question is asked or some other trigger event takes place, but stops the clock as soon as a good-enough answer becomes available—typically, when no amount of additional precision would change the users decision.

How do developers optimize online algorithms? It cant be done with other-than-real-world data or in other-than-real-world conditions. Only real-world data will show the patterns of where the variability really lies, making certain data much more important to update; only real-world conditions will show the patterns of which data takes the longest to arrive, making its estimation most worth the effort.

This means that application developers who take an online view are forced to become intimately familiar with the business problem and the business environment—to become enterprise problem solvers rather than computer scientists who happen to be on retainer to a corporate IT department. I dont need more data to know Im OK with that.

Discuss this in the eWEEK forum. Peter Coffees e-mail address is peter_coffee@ziffdavis.com.

 
 
 
 
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel