Home > Data Center

LinuxWorld - Wait! Keep reading! This is not yet another methodology that promises to solve all of your programming problems. What we'll be discussing in this article is why search has become a critical tool for developers.

Search-driven development (SDD) is an easy label that we can put on a simple fact of life in modern software development: searching for technical information is a large, costly part of creating and using information technologies.

Let's take a real-world example. Hari Jayaram is a postdoctoral researcher in biochemistry. Like all developers, he uses code written by others -- in his case, the seqhound bioinformatics API from Unleashed Informatics. And, like all developers, his code didn't "just work" the first time he ran it.

So now what? A typical developer will do things like this:

• Look for additional documentation on the API.
  
• Read newsgroups for people having the same problem.
  
• Search the company's site for help with the API.
  
• Search for code examples where other people successfully used the API. This is what Jayaram did.

What all of the above approaches have in common is that they involve search as a way to find the information needed to solve the problem at hand.

OK, you say, search helped make Jayaram happy, but that's not how I program. Heck, I don't even use open-source code, and I can GREP my own code, so what more do I need?

Good question, and one that we'll answer five different ways.

Reason No.1: We're already searching every day.

As we mentioned above, searching for technical information is a large, costly part of creating and using information technologies, and we are already paying for it whether we like it or not.

How "large and costly" is all this technical searching? Well, recent independent research says that developers spend about 25% of their time just searching for information. No wonder people worry about a "software crisis"! Between too many meetings, bad requirements, and hunting for useful information, we're stuck working long hours and still feeling like we haven't accomplished what we need to (let alone all that we really want to).

Some folks, often managers, are skeptical that developers really spend 25% of the time looking for technical information. If we break it down even a little bit, the number often seems quite low.

For example, how much of our time doing debugging is actually looking for answers in FAQs and traditional documentation, or searching blogs for people who have already run into the same problem and figured out work-arounds, or looking through mailing lists and