IEEE Spectrum ARTICLE IN ENGLISH When the Problem Is the Problem We're all fairly good at problem solving.

That's the skill we were taught and endlessly drilled on at school. Once we have a problem, we know how to turn the crank and get a solution. Ah, but finding a problemthere's the rub. Everyone knows that finding a good problem is the key to research, yet no one teaches us how to do that. Engineering education is based on the presumption that there exists a predefined problem worthy of a solution. If only it were so! After many years of managing research, I'm still not sure how to find good problems. Often I discovered that good problems were obvious only in retrospect, and even then I was sometimes proved wrong years later. Nonetheless, I did observe that there were some people who regularly found good problems, while others never seemed to be working along fruitful paths. So there must be something to be said about ways to go about this. Internet pioneer Craig Partridge recently sent around a list of open research problems in communications and networking, as well as a set of criteria for what constitutes a good problem. He offers some sensible guidelines for choosing research problems, such as having a reasonable expectation of results, believing that someone will care about your results and that others will be able to build upon them, and ensuring that the problem is indeed open and underexplored. All of this is easier said than done, however. Given any prospective problem, a search may reveal a plethora of previous work, but much of it will be hard to retrieve. On the other hand, if there is little or no previous work, maybe there's a reason no one is interested in this problem. You need something in between. Moreover, even in defining the problem you need to see a way in, the germ of some solution, and a possible escape path to a lesser result, like the runaway truck ramps on steep downhill highways. Timing is critical. If a good problem area is opened up, everyone rushes in, and soon there are diminishing returns. On unimportant problems, this same herd behavior leads to a self-approving circle of papers on a subject of little practical significance. Real progress usually comes from a succession of incremental and progressive results, as opposed to those that feature only variations on a problem's theme. At Bell Labs, the mathematician Richard Hamming used to divide his fellow researchers into two groups: those who worked behind closed doors and those whose doors were always open. The closed-door people were more focused and worked harder to produce good immediate results, but they failed in the long term. Today I think we can take the open or closed door as a metaphor for researchers who are actively connected and those who are not. And just as there may be a right amount of networking, there may also be a right amount of reading, as

opposed to writing. Hamming observed that some people spent all their time in the library but never produced any original results, while others wrote furiously but were relatively ignorant of the relevant literature. Hamming, who shared an office with Claude Shannon and knew many famous scientists and engineers, also remarked on what he saw as a "Nobel Prize effect," where once having achieved a famous result, a researcher felt that he or she could work only on great problems, consequently never doing great work again. From small-problem acorns, great trees of research grow. Like a lot of things in life, it helps to be in the right place at the right time. Sometimes all the good and well-intentioned advice in the world won't help you avoid working on a dead-end problem. I knowI've been there, done that. This article originally appeared in print as "In Research, the Problem Is the Problem."

Written by Jason Eisner in 1997, for new Computer Science Ph.D. students at the University of Pennsylvania. He was a grad student himself at the time. How to Find Research Problems by Jason Eisner The biological anthropologist Loren Eiseley used to say there were two kinds of scientists: big-bone hunters and small-bone hunters. (He himself was a small-bone hunter, he said, fitting little bits of data into the skeleton. If Eiseley had been a programmer, he would have called this "bottom-up science.") Computer science includes many different kinds of research efforts, some of which are more tyrannosaurical than others. You can contribute to one of these efforts in various ways. About the smallest bone that you can find in Computer Science is a replication or implementation of someone else's work. While this doesn't get you points for originality, it may be useful, both to your education and to the field. If you can make it useful to enough people (say, by making it portable and Web-available), it might even get your name known. A significant small bone to look for is a tweak that improves a well-known technique. (In many subfields, you will be expected to demonstrate objectively that your method is an improvement.) Much research is of this kind. When reading papers, stay on the lookout for such bones. In particular, notice when the author may be making harmful simplifications or arbitrary choices in his/her approach. These are opportunities for you to try something different.

Along the same lines, you might make a controlled comparison of two or more algorithms, evaluating them by some objective measure of efficiency or accuracy. Designing a clean comparison does take thought, and carrying it out is often a lot of work. This is usually a medium-sized bone, depending on how much work it takes and (more important) how surprising the establishment finds your results. Note that quantitative studies of this sort are becoming increasingly important in some areas of CIS (e.g., operating systems, machine learning, natural language, algorithms). You can thoroughly review the existing research in some area. Note that this takes a good deal of time to do well, and is not likely to do much for your career unless a lot of people read and cite your lit review. (To publish you'd typically need to coauthor with a famous advisor, or else find some decent journal that is willing to publish high-level overview articles by lowly grad students.) On the upside, writing a lit review will make you something of an expert, able to talk confidently with other researchers in the area; it will give you an idea of the shortcomings of past research; and it may suffice for a WPE II, an M.S.E. thesis, or the first part of a Ph.D. thesis. You can make it available to others via your Web page or an online paper archive. Build a large program or device of some kind. This gets you some name recognition, since there aren't that many big systems out there, and it also confirms your ability as a software engineer. However, do consider carefully: Will this system be of direct use to anyone? If not, will it at least beat performance records? If again not, does it have other merits, such as demonstrating how to integrate or scale up existing techniques, or introducing a collection of new techniques or a new perspective? If you are only one of many participants in a lab project, be sure that you make a ``separable contribution'' -- some piece of the work that is impressive, that stands alone, and that people will associate you with. Your field identifies various problems or issues as significant. These often represent big bones in the skeleton of the field -- problems that arise often, and whose solution makes a difference. Get to know some of these problems and the work that's been done on them. If you see how to achieve the first-ever solution, or a better solution, or a different style of solution, that's a big deal. Sometimes finding a good solution involves changing the problem slightly. If you are feeling ambitious and have a big-bone temperament, study important papers in your branch of computer science, flip through some conference proceedings to see what people are working on, and ask: What problems (recognized or unrecognized) are obstructing progress in my field? Can I solve them? If not, can I at least formalize them? Can I prove to my colleagues that solving them would make a difference?

Talk to your advisor about problems that are ripe for the plucking. Every field has its share of problems that everyone knows are ``kinda important,'' and that may even get mentioned a lot, but on which no one has yet made a serious attempt. If you think you spot such a problem, use your colleagues and the library to make sure it hasn't been plucked yet. Finally, you can identify new interesting problems. This is often not as hard as it might sound: Study existing (applied) systems and note what they do badly at. If your field is interdisciplinary, ask people in the other discipline what they think is interesting. In fact, ask them why they think computer scientists are irrelevant. In many areas, the data have a way of suggesting their own problems. Linguists can find unexplained phenomena in any magazine article. Systems programmers can collect data on actual disk access patterns and study it for regularities to exploit. Theoreticians of programming languages can look at real programming languages, and graphics programmers can look at real photographs and movies, for effects that they don't know how to capture. Keep in mind: There's lots of research out there, so you have a choice about what to work on. (Even if your advisor is very hands-on, you still have some choice.) So, especially when you are considering a time-consuming project, keep your longterm goals in mind. Will it: educate you? lead to even better projects? be an enjoyable way to spend your time? serve a goal that will still seem worthy 6, 12, or 48 months from now? be likely to "succeed" in some sense? (guideline: will it make an interesting conference talk?) escape your advisor's imprecations? get the academic research community interested in you and your work? prove to an industrial employer that you have what they want? make you a so-called ``famous grad student''? Finally: Now that you're in grad school and no one sets your agenda, everything you do is open-ended. That means you can easily spend too much time on any task you start, especially if stubborn perfectionism or an inferiority complex leads you to feel that your work is never good enough, or if you're subconsciously trying to put off that scary next phase of your research.

Don't spend eternity on background reading. Recognize that you will have to start your work in a state of partial ignorance: you don't have time to learn everything you need to know. That's okay -- your professors do the same thing. In fact it's good, since ignorance leaves your mind free to see new ways of doing things. So start doing your own thinking early. You can alternate that with reading: just show your ideas periodically to someone who can warn you about related work and point you to relevant papers. Don't spend eternity on one problem. No solution is ever complete. Take the time to make your work solid and beautiful and presentable, but recognize when you've hit a point of diminishing returns. Use project #1 to inspire project #2, which stands as research on its own. Don't use it as the core of project #1', #1'', etc. forever.

This page problems.html

online:

http://cs.jhu.edu/~jason/advice/how-to-find-research$Date: 2006/10/17

Jason Eisner - jason@cs.jhu.edu (suggestions Last Mod welcome) 01:50:52 $ PERSONAL COMMENT

Sometimes we have different tools and methodologies to solve all sorts of problems; the main drawback appears to us just when we decided to look at a problem or to inquire about a specific topic to investigate. Quite simply not have the right basis for deciding which problems to address in order to provide possible solutions, so some authors have been given the task of investigating and implementing a number of resources to enable people to access the solution of a problem, especially professionals and engineers who often are taught to solve problems, but not for trouble. Keywords: solving, problem, skill, finding, research, engineering, internet, accuracy, design

ARTICULO IEEE ESPECTRUM EN ESPAOL CUANDO EL PROBLEMA ES EL PROBLEMA Estamos todos muy buenos en la solucin de problemas. Esa es la habilidad que se ensea y perfor sin cesar en la escuela. Una vez que tenemos un problema, sabemos cmo dar vuelta a la manivela y obtener una solucin. Ah, pero encontrar un problema, ah est el problema. Todo el mundo sabe que la bsqueda de un buen problema es la clave para la investigacin, sin embargo, nadie nos ensea cmo hacerlo. Enseanza de la ingeniera se basa en la presuncin de que existe un problema predefinidos digno de una solucin. Si slo fuera eso! Despus de muchos aos de gestin de la investigacin, todava no estoy seguro de cmo encontrar buenos problemas. A menudo, he descubierto que los problemas eran evidentes buenas slo en retrospectiva, y aun as me result a veces aos ms tarde mal. Sin embargo, me hizo observar que haba algunas personas que se encuentran normalmente buenos problemas, mientras que otros nunca pareca estar funcionando a lo largo de vas fructferas. As que debe haber algo que decir acerca de las maneras de ir sobre esto. Internet pionero Craig Partridge envi recientemente en torno a una lista de problemas que la investigacin abierta en comunicaciones y redes, adems de un conjunto de los criterios de lo que constituye un buen problema. Que ofrece algunas pautas razonables para la eleccin de los problemas de investigacin, tales como tener una expectativa razonable de los resultados, en la creencia de que alguien se preocupa por sus resultados y que otros sern capaces de construir sobre ellos, y asegurar que el problema es realmente abierta y poco explorada. Todo esto es ms fcil decirlo que hacerlo, sin embargo. Teniendo en cuenta los posibles problemas, la bsqueda puede revelar una gran cantidad de trabajos anteriores, pero mucho de ello ser difcil de recuperar. Por otro lado, si existe un trabajo previo muy poca o ninguna, tal vez hay una razn est interesado nadie en este problema. Usted necesita algo en el medio. Adems, incluso en la definicin del problema tiene que ver de una manera en el germen de una solucin, y una ruta de escape posible a un resultado menor, al igual que las rampas de camiones fuera de control en la empinada cuesta abajo carreteras. El momento es crtico. Si un rea de problemas de calidad es abierta, todo el mundo se apresura, y pronto existen rendimientos decrecientes. En los problemas sin importancia, este comportamiento de rebao mismo lleva a un crculo de autoaprobacin de documentos sobre un tema de poca importancia prctica. El progreso real por lo general proviene de una sucesin de resultados incrementales y progresivos, a diferencia de aquellos que cuentan con slo variaciones sobre el tema de un problema.

En los Laboratorios Bell, el matemtico Richard Hamming se utiliza para dividir sus compaeros de investigacin en dos grupos: los que trabajaron a puertas cerradas y aquellos cuyas puertas estaban siempre abiertas. Las personas a puerta cerrada fueron ms centrado y trabajado ms duro para producir buenos resultados inmediatos, pero no en el largo plazo. Hoy en da creo que podemos tener la puerta abierta o cerrada como una metfora de los investigadores que estn conectados activamente y los que no lo son. Y as como puede haber una cantidad adecuada de redes, tambin puede haber una cantidad adecuada de la lectura, a diferencia de la escritura. Hamming observado que algunas personas pasaban todo el tiempo en la biblioteca, pero nunca produjo ningn resultado original, mientras que otros escribieron con furia, pero eran relativamente ignorantes de la literatura relevante. Hamming, que comparti una oficina con Claude Shannon y conoca a muchos famosos cientficos e ingenieros, tambin destac lo que consider un "efecto del Premio Nobel", donde una vez de haber logrado un resultado famoso, un investigador consider que l o ella podra trabajar slo en grandes problemas, por consiguiente, nunca haciendo un gran trabajo de nuevo. De pequeas bellotasproblema, los grandes rboles de la investigacin crecer. Al igual que un montn de cosas en la vida, que ayuda a estar en el lugar correcto en el momento adecuado. A veces, todos los buenos consejos y bien intencionado en el mundo no le ayudar a evitar trabajar en un problema sin salida. Lo s, he estado all, hecho eso. Este artculo apareci originalmente en forma impresa como "En la investigacin, el problema es el problema."

ARTICULO RELACIONADO

Escrito por Jason Eisner en 1997, para los nuevos Ph. D. Ciencias de la Computacin los estudiantes de la Universidad de Pennsylvania. l era un estudiante graduado en el mismo tiempo. COMO ENCONTRAR LOS PROBLEMAS DE INVESTIGACION La antroploga biolgica Loren Eiseley sola decir que haba dos tipos de cientficos: el gran hueso de los cazadores y los cazadores de pequeos huesos. (l mismo era un cazador de huesos pequeos, dijo, ajustando pequeos trozos de informacin en el esqueleto. Eiseley Si hubiera sido un programador, que han llamado a esto "de abajo hacia arriba la ciencia".) Ciencias de la computacin incluye muchos tipos diferentes de actividades de

investigacin, algunos de los cuales son ms tyrannosaurical que otros. Usted puede contribuir a uno de estos esfuerzos de varias maneras.

Sobre el hueso ms pequeo que se puede encontrar en Ciencias de la Computacin es una rplica o la ejecucin de un trabajo ajeno. Si bien esto no le consigue puntos por su originalidad, puede ser til, tanto para la educacin y al campo. Si usted puede hacer que sea til a la gente suficiente (por ejemplo, por lo que es porttil y Web disponibles), que incluso podra llegar a conocer tu nombre.

Una significativa de hueso pequeo que buscar es un pellizco que mejora una tcnica bien conocida. (En muchos subcampos, que se espera demostrar objetivamente que su mtodo es una mejora.) Muchas investigaciones de este tipo. Al leer los documentos, la estancia en la bsqueda de tales huesos. En particular, observe que el autor puede estar haciendo simplificaciones dainas o decisiones arbitrarias en su / enfoque. Estas son oportunidades para que usted pueda probar algo diferente.

En la misma lnea, es posible hacer una comparacin controlada de dos o ms algoritmos, evaluacin de las mismas por alguna medida objetiva de la eficiencia y exactitud. El diseo de una comparacin limpia tiene el pensamiento, y llevarlo a cabo es a menudo una gran cantidad de trabajo. Esto suele ser un hueso de tamao mediano, dependiendo de la cantidad de trabajo que se necesita y (ms importante), lo sorprendente de la creacin encuentra su resultado. Tenga en cuenta que los estudios cuantitativos de este tipo son cada vez ms importante en algunas zonas de la CEI (por ejemplo, sistemas operativos, la mquina de aprendizaje, el lenguaje natural, los algoritmos).

Usted puede revisar a fondo la investigacin existente en algunas reas. Tenga en cuenta que esto toma mucho tiempo para hacerlo bien, y no es probable que hacer mucho para su carrera a menos que a mucha gente leer y citar la revisin de encendido. (Para publicar habitualmente se necesita co-autor con un asesor de famosos, o bien encontrar alguna revista decente que est dispuesta a publicar artculos de alto nivel de estudiantes de posgrado visin humilde.) En la boca, escribir una resea iluminado le haga algo de un experto, capaz de hablar con confianza con otros investigadores en el rea, sino que le dar una idea de las deficiencias de las investigaciones realizadas, y puede ser suficiente para un WPE II, un MSE tesis, o la primera parte de un doctorado tesis. Usted puede ponerlo a disposicin de otros a travs de su pgina Web o un archivo de papel en lnea.

Crear un programa de gran tamao o dispositivo de algn tipo. Esto te lleva algn reconocimiento de su nombre, ya que no hay que muchos sistemas ah fuera, y tambin confirma su capacidad como ingeniero de software. Sin embargo, debe considerar cuidadosamente: Este sistema ser de uso directo para alguien? Si no, ser por lo menos registros de rendimiento de vencer? Si no es nuevo, tiene otros mritos, como demuestra la forma de integrar o ampliar las tcnicas existentes, o la introduccin de un conjunto de nuevas tcnicas, o una nueva perspectiva? Si slo uno de muchos de los participantes en un proyecto de laboratorio, asegrese de que usted hace una contribucin `` separable''- un pedazo de la obra que es impresionante, que est solo, y que la gente le asocian.

Su campo identifica varios problemas o cuestiones tan importantes. Estos a menudo representan los huesos grandes en el esqueleto del campo - los problemas que surgen con frecuencia, y cuya solucin hace la diferencia. Conozca a algunos de estos problemas y el trabajo que se ha hecho en ellos. Si usted ve la manera de lograr la solucin por primera vez, o una solucin mejor, o un estilo diferente de solucin, que es una gran cosa. A veces encontrar una buena solucin consiste en cambiar un poco el problema. Si se siente ambicioso y tiene un temperamento de gran hueso, el estudio de los documentos importantes en su rama de la informtica, flip a travs de algunas actas de la conferencia para ver lo que la gente est trabajando, y pregunte: Qu problemas (reconocidos o no reconocidos) estn obstruyendo el progreso en mi campo? Puedo solucionarlos? Si no es as, puedo menos que formalizar? Puedo demostrar a mis colegas que la solucin de ellos hacer una diferencia? Hable con su consejero acerca de los problemas que estn maduros para el desplume. Cada campo tiene su parte de los problemas que todos saben que son un poco `` importante'', y que incluso puede llegar mencionado mucho, pero en el que nadie ha hecho un intento serio. Si usted piensa que punto este problema, utilice a sus colegas y la biblioteca para asegurarse de que no se ha arrancado todava. Por ltimo, puede identificar nuevos problemas interesantes. A menudo no es tan difcil como puede parecer: Estudio existente (se aplica) y los sistemas de sealar lo que hacen mal en. Si el campo es interdisciplinario, pedir a la gente en la disciplina de otros lo que ellos piensan que es interesante. De hecho, les pregunto qu piensan que los informticos son irrelevantes. En muchas reas, los datos tienen una forma de sugerir sus propios problemas. Los lingistas pueden encontrar fenmenos inexplicables en cualquier artculo de

la revista. Programadores de sistemas pueden recopilar datos sobre los patrones reales de acceso al disco y el estudio de las regularidades que explotar. Los tericos de los lenguajes de programacin pueden ver los lenguajes de programacin real, grficos y programadores pueden ver fotografas reales y pelculas, para los efectos que ellos no saben cmo capturar. Tenga en cuenta: Hay un montn de investigacin por ah, as que usted tiene la posibilidad de elegir en qu trabajar. (Incluso si su asesor es muy prctico, usted todava tiene alguna opcin.) As que, especialmente cuando usted est considerando un proyecto de mucho tiempo, mantener su metas a largo plazo en mente. Lo: educar a usted? dar lugar a proyectos an mejor? ser una manera agradable de pasar el tiempo? para cumplir una meta que an parece digno de 6, 12 o 48 meses a partir de ahora? es probable que "tener xito" en algn sentido? (Directriz: lo har una charla interesante conferencia) escapar de las imprecaciones de su asesor? lograr que la comunidad de investigacin acadmica interesada en ti y en tu trabajo? demostrar a un patrn industrial que tienen lo que quieren? hacer que un graduado llamado `` famoso estudiante? Por ltimo: Ahora qu ests en la escuela de posgrado y nadie pone el orden del da, todo lo que haces tiene un final abierto. Eso significa que usted puede pasar mucho tiempo en cualquier tarea de empezar, especialmente si el perfeccionismo rebelde o un complejo de inferioridad le llevan a sentir que su trabajo no es lo suficientemente bueno, o si est inconsciente tratando de poner fuera de la fase siguiente del miedo su investigacin. No pasar la eternidad en la lectura de fondo. Reconozca que usted tendr que empezar a trabajar en un estado de ignorancia parcial: usted no tiene tiempo para aprender todo lo que necesita saber. Eso est bien - sus profesores hacen lo mismo. De hecho es bueno, ya que la ignorancia deja la mente libre para ver nuevas formas de hacer las cosas. As que empezar a hacer su propio pensamiento temprano. Puede alternar que con la lectura: slo mostrar sus ideas peridicamente a alguien que puede advertir de un trabajo relacionado y le indicar los documentos pertinentes. No pasar la eternidad en un problema. Ninguna solucin es siempre completa. Tmese el tiempo para hacer su trabajo slido y hermoso y presentable, pero hay que reconocer cuando se ha llegado a un punto de rendimiento decreciente. Proyecto de uso # 1 para inspirar el proyecto # 2, que se erige como la investigacin por su cuenta. No lo utilice como el ncleo del proyecto # 1, # 1'', etc siempre.

------------------------------------------------------------------------------Esta pgina en lnea: http://cs.jhu.edu/ ~ jason / consejos / how-to-findinvestigacin-problems.html Jason Eisner - jason@cs.jhu.edu (sugerencias

bienvenidas)

Mod

ltima

Fecha:

2006

10/17

01:50:52

COMENTARIO PERSONAL Muchas veces contamos con diversas herramientas y metodologas para resolver todo tipo de problemas, el gran inconveniente se nos presenta justo en el momento en el que decidimos buscar un problema o investigar acerca de un determinado tema para investigar. Sencilla y llanamente no tenemos las bases correctas para decidir qu problemas abordar para poder brindarles posibles soluciones, por eso ciertos autores se han dado a la tarea de investigar e implementar ciertos recursos que permitan a las personas acceder a la solucin de un problema, sobre todo a profesionales como los ingenieros a los cuales muchas veces se les ensea a resolver problemas, pero no a buscar problemas.

Palabras clave: resolucin de problemas, la habilidad, la bsqueda, investigacin, ingeniera, internet, la precisin, el diseo

Resolver la siguiente sopa de letras. S I N T E R N E T S E R S K I L L E A R C H G N I D N I F P R O B L E M D E S I N G O L V I N G E N G I N E E R I N G

SOLVING INTERNET RESEARCH PROBLEM DESING ENGINEERING FINDING SKILL

REFERENCIAS: http://www.cs.jhu.edu/~jason/advice/how-to-find-researchproblems.html http://spectrum.ieee.org/at-work/innovation/when-the-problem-is-theproblem