De 1969 a 1982, C. Wayne Ratliff trabajó para Martin Marietta Corporation, donde ocupó diversos puestos de ingeniería y gerencia. Fue miembro del equipo de vuelo Viking de la NASA cuando la nave Viking aterrizó en Marte en 1976 y desarrolló el sistema de gestión de datos MFILE para el software de soporte del módulo de aterrizaje Viking.

En 1978, comenzó a desarrollar el programa Vulcan, que comercializó de forma independiente entre 1979 y 1980. A finales de 1980, firmó un acuerdo de comercialización con Ashton-Tate y renombró el producto Vulcan como dBASE II. A mediados de 1983, Ashton-Tate adquirió la tecnología y los derechos de autor de dBASE II a Ratliff, quien se unió a Ashton-Tate como vicepresidente de nuevas tecnologías. Ratliff fue el director del proyecto dBASE III, además de diseñador y programador principal.

Ratliff nació en 1946 en Trenton, Ohio, y se crio en diversas ciudades y pueblos de Ohio y Alemania. Actualmente reside en la zona de Los Ángeles.

Fui a un centro de investigación de Ashton-Tate en Glendale para hablar con C. Wayne Ratliff, el creador de dBASE. Me recibió en su amplia oficina, donde nos sentamos en una mesa redonda y conversamos extensamente sobre sus logros y su visión de la programación. Ratliff es un hombre alto, de origen occidental, con un aire de independencia y un trato afable. Tras más de quince años en la industria informática, aún conserva un entusiasmo renovado. A diferencia de muchos programadores que se cansan de escribir el código fuente, Ratliff sigue disfrutando trabajando en todas las fases del desarrollo de programas a diario.

Lammers: ¿Qué te llevó a convertirte en programador?

Ratliff: Cuando estaba en la universidad, diseñaba un pequeño coche biplaza con motor trasero. Eran los años sesenta, cuando los coches eran grandes y rápidos. Así que empecé a usar un ordenador CDC 6400 para ayudarme con el diseño, porque quería adentrarme en el diseño de automóviles desde una perspectiva de ingeniería real, en lugar de simplemente adivinar qué tan grande podía ser el motor que cabía en mi diseño. Escribí varios programas pequeños para ayudarme a diseñar las suspensiones, calcular el centro de gravedad y cosas por el estilo. No tardé en empezar a buscar otros programas que escribir, porque disfrutaba más programando que construyendo el coche.

Lammers: ¿Así que la programación te alejó del diseño de automóviles?

Ratliff: Fueron las computadoras las que me alejaron del diseño de automóviles. Antes de terminar mi carrera, conseguí un trabajo en Martin Marietta en Denver. Era un computador. Mi puesto era computador. Otras personas han programado computadoras, pero yo he sido una.

Lammers: Explica eso un poco mejor.

Ratliff: Bueno, era como volver a los inicios de la ingeniería aeroespacial. Cuando había que resolver, por ejemplo, una ecuación diferencial, se contaba con un ejército de personas con calculadoras Monroe, y cada una trabajaba en una parte distinta de la ecuación. Una persona hacía una serie de sumas, luego le pasaba el papel a la siguiente para que hiciera las multiplicaciones, y así sucesivamente. A esas personas las llamaban "computadoras". En aquel entonces, las "computadoras" eran más bien como asistentes administrativos, solo que realizaban tareas relacionadas con la ingeniería en lugar de tareas administrativas. Como yo sabía programar, así es como me emplearon. Luego, en pleno fragor de la guerra de Vietnam, en 1969, me reclutaron.

Lammers: ¿Fuiste a Vietnam?

Ratliff: No. Gracias a mi trabajo en Martin Marietta, adquirí una habilidad civil, así que me dediqué a la programación. Durante dos años trabajé en un simulador de guerra logística llamado LOGEX, programando en COBOL. La mayor parte de mi trabajo consistía en gestionar pedidos de equipo y suministros. Era como hacer el inventario de una empresa enorme, solo que había que tener en cuenta políticas militares inusuales, como la necesidad de autorización presidencial para las armas nucleares.

Lammers: ¿Qué experiencias te llevaron a tu programa Vulcan?

Ratliff: Tras mi servicio militar, trabajé para Martin Marietta y como contratista en el Laboratorio de Propulsión a Chorro (JPL). Participé en el proyecto Viking y desarrollé el programa de gestión de datos para el módulo de aterrizaje Viking, llamado MFILE. Corría el año 1976, época en la que me interesé por el diseño y la experimentación con el lenguaje natural, así que compré un kit de ordenador IMSAI 8080 de 8 bits y lo monté. Tardé un año en ensamblarlo, principalmente esperando las piezas. Tuve que soldar más de 2200 puntos. Claro que, si hubiera podido comprarlo ya montado por el mismo precio, o uno similar, lo habría hecho.

Una vez que lo armé, lo único que tenía era una computadora. No incluía nada más que 1 KB de memoria. Tenía que ir comprando cosas por separado, como el teclado. Ya había gastado $1000 en el kit, y luego tuve que gastar otros $159 en un teclado. Al final, terminé gastando unos $6000. Ahora se puede comprar una AT, con disco duro, completa y lista para usar por $6000.

Lammers: ¿Fueron sus experimentos con lenguaje natural la base de dBASE?

Ratliff: dBASE surgió, curiosamente, a partir de partidos de fútbol. Participaba en una quiniela donde se elegía al ganador y luego el margen de puntos. Nunca supe mucho de fútbol. Lo que me interesaba era la motivación para ganar, más que el juego en sí. Pensaba que si me dedicaba con ahínco al proceso matemático, podría ganar.

La forma de hacerlo era analizar todas las estadísticas. Cada lunes por la mañana, el periódico publica todas las estadísticas de los partidos del fin de semana; ocupan al menos dos páginas. Unas cuatro o cinco semanas después de empezar la temporada, ¡tenía una habitación entera cubierta de periódicos! Intentaba averiguar cómo elegir un ganador consultando periódico tras periódico, un proceso horrible, y decidí que era demasiado complicado sin un ordenador. Bueno, una cosa llevó a la otra, y en una semana, me había olvidado por completo del fútbol. Había decidido que el mundo necesitaba un gestor de bases de datos de lenguaje natural. Obviamente, el ordenador era la solución, y por eso compré el IMSAI 8080.

Me puse a comprar muchos libros sobre lenguaje natural e inteligencia artificial. Iba de un tema a otro y realicé muchos experimentos. No había investigado tanto sobre bases de datos como sobre el procesamiento del lenguaje natural.

Decidí usar el gestor de bases de datos como base para trabajar con el lenguaje natural. El lenguaje natural en sí mismo es un gran "¿y qué?". Necesitaba algo sobre lo que pudiera actuar. Empecé a pensar en el programa de gestión de datos que había escrito para Viking, y básicamente iba a duplicarlo en la máquina de 8 bits, la IMSAI. Por casualidad, me topé con la descripción de un programa llamado JPLDIS, o Sistemas de Información y Visualización del JPL. Era fácil de entender, muy sencillo y muy claro. Enseguida pensé que sería fácil de implementar en un microordenador.

Creo que JPLDIS era, en realidad, un clon o una copia de un producto de IBM llamado Retrieve, que funcionaba en algunos sistemas de tiempo compartido. Así que hay una especie de progresión desde Retrieve a JPLDIS y a mi programa, al que llamé Vulcan. Iba a ocuparme primero de la base de datos y luego del procesamiento del lenguaje natural, pero lo pospuse y todavía no lo he desarrollado.

Lammers: ¿Qué forma adoptó esta primera versión del programa dBASE, o Vulcan?

Ratliff: Tomé el concepto de JPLDIS, reduje las especificaciones y desarrollé Vulcan. JPLDIS podía manejar doscientos campos, pero pensé que dieciséis eran suficientes. Logré que funcionara y, poco más de un año después de empezar, lo usé para declarar impuestos. Así que intuí que Vulcan tenía potencial comercial y comencé a perfeccionarlo para que estuviera listo para la venta. En octubre de 1979, lo lancé al mercado y publiqué mi primer anuncio de Vulcan en la revista BYTE, y mantuve un anuncio de un cuarto de página durante cuatro o cinco meses. Recibí muchísimas respuestas, más de las que podía gestionar.

Lammers: Su respuesta fue inmediatamente positiva. ¿Quiénes eran sus competidores en ese momento?

Ratliff: FMS 80, y más tarde Condor y Selector. Durante el año y nueve meses que estuve programando Vulcan, mi disquetera se averió dos veces. Tardaba tres meses en repararla, así que perdí seis meses. No dejaba de pensar que, si hubiera terminado seis meses antes, habría sido el primero.

Lammers: De repente, tenías un producto que estaba penetrando en el mercado. ¿Te sorprendió este éxito?

Ratliff: Me estresé muchísimo. Lo hacía todo yo solo. Cuando llegaba un pedido, lo transcribía, rellenaba la factura, empaquetaba el programa, hacía una copia nueva del disco... todo el proceso. Publicaba todos los anuncios yo mismo y, además, seguía trabajando en el programa. Llegaba del trabajo, trabajaba hasta medianoche, me iba a dormir agotado, me levantaba al día siguiente y repetía el proceso. Vulcan estaba en un punto en el que necesitaba hacerle muchos avances. Con el paso de los meses, me quedé sin fuerzas.

En el verano de 1980, decidí dejar de anunciar Vulcan y dejar que desapareciera por completo. Seguiría ofreciendo soporte a quienes lo habían comprado, pero no iba a buscar activamente nuevos compradores.

Lammers: ¿Por qué no intentaste vendérselo a una empresa más grande o contratar ayuda?

Ratliff: No se me ocurrió. En aquel entonces no existían las grandes empresas. Que yo supiera, todo el mundo era muy pequeño. Un profesor de la Universidad de Washington y su esposa estaban considerando hacerse cargo del marketing cuando George Tate y Hal Lashlee llamaron. Vinieron a casa y vieron una demostración; aunque siempre surge algún problema durante una demostración, fueron comprensivos, conocían el tema. Me impresionó mucho. La mayoría de la gente, al ver una demostración, pierde el interés en cuanto algo falla. George y Hal ya tenían una empresa llamada Discount Software. Tenían un empleado; lo decían como si tuvieran un montón, pero en realidad solo tenían uno. Además, estaban cerca, a unos dieciséis o veinticinco kilómetros. Me pareció una opción lógica. Me ofrecieron los derechos exclusivos de marketing y acepté. Seguimos con ese acuerdo durante dos o tres años.

Lammers: Cuando escribiste Vulcan, ¿tenías alguna idea de que tendría tanto éxito?

Ratliff: Pasé por varias etapas. Antes de empezar a promocionarlo yo mismo, tenía la ilusión de que si el diez por ciento de los lectores de BYTE lo compraban, podría dejar mi trabajo y jubilarme. Esa idea no duró mucho. Cuando no llegó la primera avalancha de pedidos, revisé mis expectativas. Incluso después de cerrar el acuerdo con Ashton-Tate, anoté en mi diario que esperaba obtener una ganancia neta de 100.000 dólares. En total. Creo que eso indicaba lo conservadoras que se habían vuelto mis aspiraciones.

Lammers: Hablemos de la transición de Vulcan a dBASE. ¿Qué tipo de avances se realizaron en Vulcan que condujeron al producto actual?

Ratliff: Se realizaron algunos avances en la interfaz de usuario y algunas mejoras en el rendimiento, pero el cambio principal fue pasar de una orientación tipo teletipo a una de pantalla completa. Tras ver DamStar, me di cuenta de que la pantalla bidimensional era donde todos querían estar.

Los nuevos comandos que añadí estaban casi exclusivamente en la interfaz de usuario. Creo que nunca llegué a incorporar todos los avances necesarios. Entiendo que la percepción actual de dBASE es que el programa no es muy intuitivo. Creo que, en retrospectiva, si hubiera seguido mi intuición en lugar de los consejos, dBASE estaría mucho más cerca de la perfección hoy en día.

Lammers: Pero es un producto muy exitoso y con muy buenas reseñas. ¿Será que solo habla tu lado perfeccionista?

Ratliff: Recibí consejos sobre diversas cosas: hacerlo más grande, más rápido, más pequeño, pasarlo a 16 bits, hacerlo multi-usuario, añadirle varios idiomas: francés, inglés, neerlandés, alemán... Había tantas sugerencias que intenté abarcarlas todas un poco. Al final, creo que ese fue mi error.

Mi intención era hacer el programa más potente y fácil de usar. Si me hubiera mantenido fiel a eso, el programa sería mejor hoy en día, pero no estoy seguro de que hubiera tenido más éxito. Quizás los consejos que recibí eran acertados. En muchos sentidos, me cuesta imaginar cómo el programa podría haber tenido más éxito en términos de ventas.

Lammers: ¿Por qué crees que dBASE tiene tanto éxito?

Ratliff: Hubo muchísima suerte. Pero dBASE también fue el programa adecuado en el lugar y momento precisos, y eso no es solo suerte, sino diseño. El hecho de que sea un lenguaje, además de un gestor de bases de datos, resultó ser enormemente importante.

dBASE captó la atención de la gente por su gran flexibilidad. Toda mi vida he programado como un creador de herramientas. Si me comparo con otros programadores, incluso de hace diez años, veo que yo intentaba generalizar en gran medida; ellos intentaban escribir programas que resolvieran una necesidad específica. Sus programas solían estar listos mucho antes que los míos, pero los míos tenían una vida útil más larga. Una vez que la necesidad específica desaparecía, sus programas quedaban obsoletos; había que reescribirlos cada vez que cambiaban las necesidades. Siempre he programado de forma que el programa pudiera resolver una variedad de problemas, en lugar de uno solo.

dBASE se diferenciaba de programas como BASIC, C, FORTRAN y COBOL en que gran parte del trabajo pesado ya estaba hecho. La manipulación de datos la realiza dBASE en lugar del usuario, por lo que este puede concentrarse en lo que está haciendo, en vez de tener que lidiar con los engorrosos detalles de abrir, leer y cerrar archivos, y administrar la asignación de espacio.

Lammers: ¿Así que, desde el principio, tuviste en mente al usuario durante el diseño de dBASE?

Ratliff: ¡Por supuesto! Con frecuencia me preguntan: "¿Lo hacemos así o asá?". Intuitivamente, me pregunto: "¿Qué quieren los usuarios? ¿Cómo van a usar esto? ¿Qué beneficio les aporta?". Muchos programadores solo piensan en cómo programar algo. Nunca han vendido ni hecho marketing. Son muy buenos programadores, pero no piensan en el mercado real.

Lammers: En ese sentido, ¿aconsejaría a los programadores que se centren menos en la tecnología y más en los usuarios y el mercado?

Ratliff: Sí. ¿Crees que "hacker" es una palabra buena o mala? Si crees que es buena, entonces son hackers. Son buenas personas, pero piensan más en su trabajo que en el usuario y hay que ir un poco más allá. Así fue como surgió dBASE. Estaba pensando en cómo quería usarlo.

Lammers: Has presenciado grandes transformaciones en el sector desde que te incorporaste. ¿De qué manera han cambiado tus técnicas de programación con el paso del tiempo?

Ratliff: Los cambios no provienen de lo que he aprendido, sino de los cambios en la informática. Cuando empecé a trabajar con ordenadores, siempre grababa los programas en tarjetas perforadas y los ejecutaba por lotes. Llevaba mi juego de tarjetas al operador y le rogaba, le entregaba mi trabajo y luego volvía cada media hora a revisar la ventana para ver si se había ejecutado e impreso. En general, escribía un programa entero en papel, borraba y editaba mucho, y luego se lo daba a un operador de la perforadora para que grabara el juego de tarjetas. Ese era el enfoque del big bang: escribías todo el programa e intentabas que funcionara bien en papel. Ejecutarlo en un ordenador era simplemente conseguir que funcionara. No había una mejora gradual.

Hoy en día, con los monitores CRT, puedes escribir el programa tú mismo. Con los ordenadores personales, el tiempo de respuesta es casi instantáneo, pero no son tan potentes como las grandes máquinas, así que puede llevar mucho tiempo compilar y ejecutar. Así que suelo escribir unas pocas líneas a la vez, probarlas, hacer que funcionen y luego escribir algunas más. Intento realizar el mínimo esfuerzo posible en cada iteración para lograr un cambio sustancial. Por eso, ahora la programación es mucho más evolutiva, mientras que antes era como un big bang.

Lammers: ¿El producto final suele diferir mucho de tu plan inicial?

Ratliff: En cierto modo, sí. Siempre se me ocurren ideas y sugerencias sobre la marcha. Cuando planifico un proyecto ahora, termina abarcando prácticamente todo lo que había planeado inicialmente, e incluso mucho más. O, cuando empiezo a experimentar con él, veo una oportunidad de mejora. Siempre estoy buscando oportunidades de cualquier tipo.

Lammers: ¿Sigues programando hoy en día?

Ratliff: No tanto como me gustaría. Me involucro demasiado en el negocio.

Lammers: Sí, parece que muchos programadores con programas exitosos se alejan de sus raíces originales y son trasplantados a puestos de gestión...

Ratliff: Eso me ha pasado muchas veces, pero mi participación en la gestión va a disminuir, incluso desaparecer. Espero que así sea, porque la gestión consume muchísimo tiempo. Cuando vengo a la oficina, no programo nada. Hablo, ya sea por teléfono, en persona o en reuniones. Prácticamente toda mi programación la hago en casa.

Lammers: ¿Cómo logras conciliar tu vida familiar con el trabajo y las intensas jornadas de programación nocturna?

Ratliff: Por lo general, trabajo en proyectos de programación cuando mi esposa, Carolyn, me lo permite. Antes de casarme, bueno, entre matrimonios, trabajaba hasta casi la medianoche. Me gusta trabajar de noche porque no hay distracciones. No suena el teléfono, no viene el cartero ni el jardinero. Hay silencio, así que tengo tiempo para concentrarme.

Lammers: ¿Te has decidido por un estilo de trabajo concreto que consideres realmente productivo para tus propios fines?

Ratliff: Trabajo bien solo o con grupos muy pequeños. Cuando un grupo supera las seis personas, se descontrola por completo. Ted Glasser, quien posee varias patentes, es una figura destacada en la industria informática y figura en Who's Who, una vez comentó que el equipo más grande que podía gestionar era uno que cupiera en un Volkswagen para ir a comprar pizza. Desde entonces, ha cambiado de opinión: ahora usa un coche americano de tamaño normal. Estoy totalmente de acuerdo.

En cuanto a múltiples proyectos, generalmente me dedico exclusivamente a uno solo. Si cambio de proyecto, es un cambio total. Puede que tenga que dejar algo de lado, y puede que permanezca en segundo plano, sin trabajar en él durante meses, para luego retomarlo. Esa es la única forma en que gestiono varios proyectos a la vez. Una vez que empiezo un proyecto, me gusta terminarlo. Puede que no lo deje completamente terminado, pero sí en un estado aceptable. Tiene que haber una buena razón para que deje algo de lado. Algo más importante, como la culpa. La culpa funciona bien. Si siento que estoy incumpliendo un compromiso con alguien, dejo de lado algo que realmente me gusta.

Soy el tipo de programador al que le gusta planificar, pero no lo planifico todo con un detalle infinito. Tengo una idea de cuál es el objetivo, pero el verdadero trabajo consiste en descubrir cuál es el siguiente paso para alcanzarlo. Intento hacer lo mínimo necesario para avanzar un paso más. Dentro de un objetivo, dentro de un paso, tomo el subconjunto mínimo. No empiezo por la parte más difícil, ni por la más fácil. No se define matemáticamente, sino emocional e intuitivamente.

Lammers: ¿Entonces no te consideras una persona detallista?

Ratliff: No, me ocupo de los detalles porque sé que hay que hacerlos. No es algo que disfrute. Es decir, recortar nanosegundos me parece totalmente irrelevante. Si el programa funciona a la mitad de la velocidad que crees que debería, sabes que dentro de un año, con la nueva maquinaria, funcionará perfectamente.

Lammers: ¿Qué es lo que te satisface de la programación?

Ratliff: Bueno, el coche deportivo personalizado en el que trabajé fue un proyecto muy gratificante porque podía crear algo y verlo materializarse ante mis ojos. El mayor problema fue que necesitaba piezas que no existían. Con los ordenadores, si necesito algo a medianoche y no lo tengo, puedo crearlo, sea lo que sea. Lo peor que puede pasar es que tarde mucho en hacerse.

Claro que eso no es todo lo que me gusta de la programación. Me gusta la alta tecnología, me gusta poder crear algo y verlo reflejado en la pantalla. Si programas bien, el resultado es elegante; fluye con naturalidad, está bien estructurado. Lo disfruto desde el punto de vista de la ingeniería, igual que un coche bien construido, un puente bien construido o un edificio bien construido. Todo en él parece estar en equilibrio, perfectamente ajustado.

Lammers: ¿Podrías profundizar en esta sensación de equilibrio y elegancia?

Ratliff: El equilibrio se manifiesta de muchas maneras. El código debe ser claro y conciso. Cualquier módulo debe poder explicarse en una sola frase y, de ser posible, debe estar en orden alfabético. Visualmente, la sangría no debe salirse del borde del papel en ningún momento. No debe haber una instrucción "if" demasiado grande ni una instrucción "else" demasiado pequeña. Todo debe estar equilibrado. El equilibrio es fundamental.

Lammers: Cuando escribes código, ¿sale equilibrado a la primera o necesita muchos cambios?

Ratliff: Hago muchos cambios. Me gusta comparar la programación con esculpir una figura de arcilla. Empiezas con un trozo de arcilla, lo vas raspando, añades más y vuelves a raspar. De vez en cuando, decides que una pierna no se ve bien, así que la quitas y le pones una nueva. Hay mucha interacción.

El módulo ideal debería ocupar una página. Si se extiende más allá de una página, tengo que decidir: ¿qué estoy haciendo aquí? ¿En cuántas cosas distintas estoy trabajando? ¿Debería dividirlas en módulos separados? Parte de la elegancia y el equilibrio reside en que, en cierto nivel, dentro de esta jerarquía de capas del programa, todos los módulos deberían tener aproximadamente el mismo peso, tamaño, función y características.

Lammers: ¿Cómo ayuda el equilibrio a un programa?

Ratliff: El programa se vuelve mantenible. Cuando se logra un buen equilibrio, es como si se hubiera descubierto y aplicado un principio físico fundamental. Cuando las cosas se desequilibran por completo, se sabe que algo anda mal. Probablemente exista algún fallo inherente que cause el desequilibrio. Generalmente, cuando tengo la sensación de que algo no funciona bien, sobre todo cuando un módulo es demasiado grande, reflexiono sobre lo que estoy haciendo y reorganizo o reajusto las partes.

Lammers: ¿Alguien en particular ha influido en tu programación?

Ratliff: Me impresionó mucho un libro de Gary Meyer, llamado "Software Reliability". Otros libros también me han influenciado de maneras muy sencillas. Ordenar las cosas alfabéticamente es un truco que aprendí de libros sobre estilos de programación. Simplifica las cosas, hace que el programa sea más limpio y es un paso hacia la elegancia. Es la simplicidad absoluta: no me explico por qué no se me ocurrió antes.

Otra influencia fue uno de mis jefes en Martin Marietta, Phil Carney. En aquel entonces escribía programas en FORTRAN, y cuando necesitaba un nuevo número de instrucción, elegía el siguiente en orden. Uno no piensa en esas cosas en orden a medida que avanza el programa, así que las elegía arbitrariamente. Cuando me vio hacerlo, se irritó y me dijo: "Ordena estas cosas, empezando por el cien y aumenta de diez en diez". Me pareció muy lógico. Son detalles pequeños, pero los detalles pequeños realmente ayudan.

Lammers: ¿Te cansas alguna vez de programar?

Ratliff: Cuando me doy cuenta de que hago lo mismo una y otra vez, me aburro. Recuerdo tener la vaga sensación en el JPL de que estaba escribiendo el mismo bucle una y otra vez. Todo era un poco diferente cada vez que lo hacía, pero el bucle era básicamente el mismo. Un día, hojeando el libro de Programación Estructurada, vi por casualidad un diagrama de flujo de diseño de programación estructurada y pensé: "Esto es lo que necesito". Y así fue.

Lammers: ¿Escribes muchos comentarios en tus programas?

Ratliff: En realidad, no. Me han criticado en esta empresa por no escribir muchos comentarios. Creo que hay dos tipos de comentarios: uno que explica lo obvio, que es peor que inútil y otro que explica código realmente complejo y enrevesado. Bueno, siempre intento evitar el código enrevesado. Intento programar código sólido, claro y limpio, aunque implique cinco líneas adicionales. Casi diría que cuantos más comentarios necesite un programa, peor es y algo falla. Un buen programa no debería requerir muchos comentarios. El programa en sí debería ser el comentario.

Los módulos deberían ser relativamente pequeños. Si un módulo supera una página de código, algo falla. Sin duda, se necesita una línea de comentario al principio de cada módulo que explique su función en una frase. Si no se puede explicar en una frase, algo falla.

Lammers: ¿Qué cualidades distinguen a un programador excepcional?

Ratliff: Existe un espectro en la programación. En un extremo está el programador que trabaja exclusivamente para el usuario; en el otro, el que se centra en resolver algún problema matemático y no le importa en absoluto el usuario. Curiosamente, los guionistas de videojuegos son quienes mejor comprenden al usuario. Las matemáticas del juego probablemente les resulten irritantes, mientras que, en el otro extremo, al programador que crea un algoritmo mejor de raíz cuadrada le resulta irritante decidir si se mostrará en la parte superior o inferior de la pantalla. Me considero a tres cuartos del camino hacia el guionista de videojuegos, más enfocado en la interfaz de usuario.

No se puede comparar todo el espectro, pero sí se puede comparar dentro de él. Theodore Sturgeon dijo que el 90% de todo es basura. No andaba muy desencaminado. Quizás sea un poco pesimista: tal vez un 60, 70 u 80 por ciento. Hay pruebas muy claras de que el 3% de la población, en cualquier subconjunto identificable, realiza el 10% del trabajo, y por otro lado, el 50% solo realiza el 30% del trabajo total. Esto aplica a mariscales de campo de fútbol americano, programadores, periodistas y a todos los demás. Siempre hay algunos que trabajan seis veces más que ese 50%. Así que hay buenos y malos programadores, al igual que hay buenos y malos empleados en todos los ámbitos.

Lammers: ¿Desarrollar un programa es un proceso doloroso o placentero?

Ratliff: Es un poco de ambas cosas. Programar se parece un poco al ejército. Cuando estaba en el ejército, lo odiaba profundamente. Lo detestaba cada minuto. Ansiaba salir. Pero ahora que estoy fuera, es genial haber tenido la experiencia. Cuando programo, disfruto resolviendo pequeños detalles en el proceso, y cuando termino, es gratificante haberlo logrado, pero aun así preferiría ser más productivo en el mismo tiempo. Así que, también hay una pequeña dosis de sufrimiento constante.

El momento de programación que más disfruto es cuando tengo algo casi terminado. Lo intento por primera vez, falla estrepitosamente y sigue fallando hasta la centésima vez, cuando funciona bastante bien. Hay una satisfacción máxima ahí, porque entonces sé que lo he conseguido. Solo tengo que esforzarme un poco más para eliminar los últimos errores.

Lammers: ¿Es el trabajo de un programador tan individual que alguien podría mirar su código y decir: "Esto lo escribió C. Wayne Ratliff"?

Ratliff: Bueno, Gary Balleisen, autor de SuperCalc y usuario del código fuente de las primeras etapas de dBASE, afirma poder identificar la autoría de cada código mediante una firma de estilo. Sé que algunas de mis prácticas, como la forma en que termino los bloques, difieren de las de los demás. Y estoy convencido de que mi método es, con diferencia, el mejor.

Por ejemplo, cuando vi C por primera vez, no me gustaban esas llaves que sobresalían tanto a la izquierda en el código. Me resultaban confusas. Pero, por casualidad, encontré en la documentación de Digital Research una técnica que recomendaba colocar esos terminadores al mismo nivel que el código indentado. Resulta que ese es otro de esos pequeños cambios que marcan una gran diferencia. Y he intentado convencer a todos de que esta es la forma correcta de hacerlo. Con un éxito moderado. Incluso modifiqué un programa, un formateador de código C, para que lo hiciera automáticamente. Puedo tomar el código de otra persona y ejecutarlo con este programa y ​​se indentará a mi forma.

Lammers: ¿Has explorado alguna vez el campo de la inteligencia artificial?

Ratliff: Al principio de este negocio, estuve muy involucrado en la IA. Hace poco más de un año, me decanté por la IA porque pensaba que era el futuro. Pero me he alejado de ella.

La IA tiene futuro, pero no es inmediato. En primer lugar, está el problema del lenguaje natural. Si tienes un sistema de lenguaje natural, lo compras, lo instalas en tu ordenador y tienes que pasar por un proceso de semanas, quizá meses, para enseñarle el significado de tus palabras. Una misma palabra tiene distintos significados en diferentes contextos. Incluso una palabra aparentemente sencilla, como "beneficio", puede tener varios significados. Debe definirse con mucha precisión, según el sector en el que operes, cómo lleves la contabilidad, etc. Este largo proceso necesario para entrenar a la máquina hace que la IA sea un producto listo para usar.

Pero la otra cara de la moneda, muy interesante, son los sistemas expertos. Predigo que en los próximos dos o tres años, los sistemas expertos ya no se asociarán con la inteligencia artificial. Esa ha sido la historia de la IA: cuando algo empieza a ser bastante conocido, se bifurca. El reconocimiento de patrones solía considerarse IA, pero ahora es un campo aparte. Ese es el destino inmediato de los sistemas expertos. Creo que los sistemas expertos van a ser muy importantes en nuestra industria, de forma análoga a las aplicaciones verticales.

Lammers: ¿Crees que habrá cambios importantes en nuestra concepción de los programas, en cuanto a la forma en que trabajamos con ellos y los gestionamos? ¿Quizás un nuevo lenguaje tan sencillo y fácil de usar que cualquiera pueda programar?

Ratliff: Habrá cierta evolución. Algunas de las características arcanas desaparecerán gradualmente. Un lenguaje como dBASE tiene algunos defectos importantes, pero con el tiempo estos desaparecerán mediante un proceso evolutivo progresivo. Y siempre podemos cruzar los dedos y esperar que se produzca algún avance significativo, como ocurrió con las hojas de cálculo en sus inicios. Espero que en el futuro surja algo tan ingenioso, pero es totalmente impredecible.

Me fascina un programa de UNIX llamado yacc que genera un analizador sintáctico. Se le proporcionan las especificaciones del lenguaje en formato Backus-Naur (BNF), ampliamente aceptado en la industria de la informática. Genera un módulo en C que analiza sintácticamente un lenguaje que se ajusta a las especificaciones. Me encantaría poder hacer eso para un programa de nivel superior. Idealmente, se escribiría el programa como especificaciones, luego se compilaría y el resultado sería el programa. Probablemente se podría escribir algo del tamaño de dBASE en un mes.

Lammers: ¿Alguna vez has pensado en retirarte de la programación?

Ratliff: No. Tengo la plena confianza de seguir programando durante muchos años. Mi esposa a veces sueña que nos desharemos de todos los ordenadores y dedicaremos todo nuestro tiempo a nuestros caballos y yo le digo: "Un momento, eso no es lo que quiero". Me gustaría eliminar el estrés, pero no quiero dejar de programar.

Lammers: Cuando se completa un proyecto tan intenso como dBASE, ¿existe una sensación de anticlímax al finalizar?

Ratliff: Es entonces cuando tienes que pensar en un nuevo proyecto. Un programa es muy divertido al principio, cuando tienes las primeras ideas sobre lo que puede hacer. Esas ideas crecen muy rápido. Surge una pequeña chispa y luego le vas añadiendo otras funcionalidades. Cuando esa euforia se desvanece y tienes que empezar a programar, la cosa se complica.

Antes pensaba que todo el mundo era diseñador en este sector. Iba a casa de George Tate, bebíamos cerveza y comíamos pizza y muchas veces Hal, George y yo nos reuníamos media hora antes de empezar a beber y en media hora podía planificar el trabajo de un año. Todo el mundo quiere encargarse del diseño. La implementación, el trabajo del año y todo lo demás se lo dejan a otros.

Lammers: Pero tú no haces eso en absoluto. Tú lo escribes además de diseñarlo.

Ratliff: Sí, pero gran parte del diseño es un proceso continuo; no se trata de una idea brillante seguida de una implementación inmediata. Uno de los problemas con los que esta empresa está lidiando es encontrar la mejor manera de desarrollar software.

Por alguna razón, no sienten que puedan confiar en las personas, o al menos en un pequeño grupo de ellas. El procedimiento actual es el siguiente: Marketing define la función del programa; luego, Marketing comunica al equipo de Desarrollo su interpretación; entonces, Desarrollo dedica varios meses a redactar una especificación muy detallada de lo que cree haber entendido; posteriormente, varias personas dentro de la empresa revisan dicha especificación y negocian las funciones exactas. Una vez finalizado el trabajo más complejo, solo queda programar.

Este proceso podría ser apropiado para la construcción de puentes, ya que se conoce con precisión su función. Debe conectar una orilla del río con la otra, y se puede especificar con exactitud el peso máximo que soportará, así como todos los demás detalles, con antelación. De hecho, con un puente de mando, imagino que se puede especificar todo en una sola hoja. Creo que esa es la especificación que debería tener un programa informático: una sola hoja.

En la empresa hay consenso en que el proceso actual no funciona o es tan engorroso que no merece la pena. Es mejor encontrar a alguien con una idea, darle una pequeña compensación, dejarle trabajar sin trabas durante un tiempo prolongado y, cuando crea haber terminado, permitir que otros trabajen con el programa y hagan sugerencias para mejorarlo.

También es importante probar el programa con usuarios reales para asegurarse de que satisface sus necesidades. Y ahí es donde esta empresa se equivoca: ignora a los usuarios. Se han centrado demasiado en el marketing y en realidad están luchando contra otros profesionales del marketing. Todos los anuncios los hacen los especialistas en marketing, no los usuarios que dicen: "Esto es lo que necesitamos". Es un especialista en marketing intentando demostrar su valía frente a otro, librando una batalla de especificaciones. Y creo que eso está mal. Puedes verte genial en los anuncios, ¿y qué? Lo que ha impulsado el éxito de dBASE no han sido sus anuncios, aunque, en retrospectiva, creo que los primeros eran excelentes.

Lammers: ¿Cuál fue la primera campaña publicitaria?

Ratliff: Ese era el anuncio de Hal Pawluk que comparaba dBASE con la bomba de achique. En su momento, fue un anuncio bastante provocador.

Lammers: ¿Por qué?

Ratliff: La primera frase del anuncio decía: "Todos sabemos que las bombas de achique son un desastre". La empresa que fabrica esa bomba de achique en particular le escribió una carta a George Tate, diciéndole que no les gustaba que su bomba de achique se mostrara de forma peyorativa. George dijo: "De acuerdo, pondremos una pequeña nota al final del anuncio que diga que esta bomba de achique en particular no es un desastre". Por alguna razón, tampoco les gustó ese anuncio.

Lammers: Es un anuncio bastante bueno. Supongo que antes los negocios no eran tan rígidos como ahora. ¿Echas de menos ese tipo de cosas?

Ratliff: Sí, claro. De hecho, ahora mismo no me estoy llevando bien con la empresa. Tenemos muchos problemas. Soy emprendedor y, como tal, me gusta empezar de cero y crear algo. Algunos prefieren llevar algo pequeño a través de la fase de crecimiento hasta convertirlo en algo grande y otros prefieren tomar algo grande y desarrollarlo hasta que alcance una fase aún mayor, la fase de madurez. Hay tres fases. Creo que dos fases adyacentes cualesquiera son bastante compatibles, pero siento que estoy en la primera fase intentando ser compatible con la tercera. Eso está generando mucha fricción.

Lammers: Es un buen análisis. Parece que también está ocurriendo en el sector. Está alcanzando una etapa de gran envergadura, las empresas han crecido exponencialmente y ahora la gente tiene que lidiar con ello, y están frustrados...

Ratliff: Pero el software no ha cambiado. Lo que ha cambiado son las empresas. Hay indicios de que la actitud de estas empresas es errónea. Sin duda, se necesita visión empresarial para dirigir una empresa, pero, en cierta medida, quienes se incorporan al sector ahora mismo no comprenden la verdadera naturaleza del software. Se dedican al mundo empresarial, no al del software.

Lammers: ¿Qué es el software, en el contexto de esa observación?

Ratliff: Idealmente, se trata de lograr que una computadora haga algo beneficioso que, en última instancia, ayude a las personas. No soy tan altruista; ese no es mi objetivo. Mi objetivo es escribir software ingenioso, programas que representen un reto. No es mi misión resolver necesidades sociales, pero ese puede ser otro resultado positivo del software.

Lammers: ¿Consideras la programación informática un arte, una ciencia, una habilidad, un oficio...?

Ratliff: Creo que hay algo de ciencia y algo de arte. Cuanto más humanizado se vuelve, más arte tiene. Los guionistas de videojuegos trabajan principalmente con una forma de arte en la pantalla, y utilizan un producto de alta tecnología para plasmarla y transmitirla. Estarías en una situación muy similar si realmente tuvieras que comprender la composición química de la arcilla para ser escultor. Puedes aprender lo suficiente para esculpir arcilla en pocos minutos, pero dominar un ordenador requiere tiempo y, más que tiempo, requiere pasión.

Lammers: ¿Qué sigue después de dBASE?

Ratliff: Las oportunidades están cambiando de alcance. Con las tres herramientas clásicas de productividad (bases de datos, procesadores de texto y hojas de cálculo), no hay mucho espacio para nuevos competidores, aunque siempre hay aspirantes. Fíjense en Paradox: intentan convertirse en la base de datos líder o al menos ganar cuota de mercado. Y está Javelin; se supone que va a desbancar a las tres primeras. No estoy seguro de a quién pueden desbancar ahora mismo. Ningún procesador de textos tiene la cuota de mercado dominante, pero varios tienen una parte considerable. Entre Microsoft Word, Multimate, WordStar, WordPerfect, Samna y otros quinientos, no hay muchas oportunidades para crear un nuevo procesador de texto exitoso.

Hay muchas oportunidades, pero no en esas áreas. Creo que hay muchas oportunidades para que las empresas tengan éxito comercializando sistemas expertos; no solo las interfaces, sino también las bases de conocimiento, que abordan una amplia gama de problemas. Con ese tipo de sistema experto, se podría acceder a docenas de mercados verticales.

Lammers: ¿Crees que es posible diseñar un sistema que pueda dar cabida a una docena de esos mercados verticales?

Ratliff: Posiblemente. Al menos puedes abordarlos de uno en uno. Incluso si existen mil mercados verticales, cada uno de ellos tiene varios miles de compradores potenciales. E incluso si solo te enfocas en uno a la vez, teóricamente, si creas un buen producto para un mercado vertical pequeño, podrías alcanzar un nivel cercano a la saturación, ya que tienden a ser bastante cerrados.

Lammers: ¿Crees que IBM seguirá dominando el mercado?

Ratliff: Creo que sí. Me parece que Apple fracasó en todos los aspectos. Fallaron estrepitosamente en el ámbito comercial, y creo que eso probablemente les perjudicó en el mercado doméstico. Creo que hay cierta desilusión respecto al potencial del Macintosh. AT&T parece estar estancada, y ninguna de las demás compañías parece estar haciendo una oferta muy fuerte. Supongo que lo que mantiene a IBM en la cima son todos los clones.

En realidad, me gusta cómo está el mercado ahora mismo; la competencia obliga a IBM a innovar y los competidores saben que si no innovan frente a IBM, saldrán perjudicados. Si esto se mantiene, sería bueno. Mientras que las demás compañías se mantienen compatibles con IBM e incluso en muchos aspectos tienen un producto superior, se ven obligadas a mantenerse a raya por la presencia de IBM. Me gustaría que todos vivieran felices para siempre. Cuando IBM era mucho más fuerte en el mercado de los mainframes, realmente me disgustaban los ordenadores IBM.

Las 360, 370, 3030x y la serie 4340 no me gustaron nada. Me alegró mucho ver la firma del acuerdo entre Microsoft e IBM. Temía que IBM desarrollara su propio sistema operativo, y ya he visto sistemas operativos desarrollados por IBM.

Lammers: ¿Alguna vez reflexionas sobre el pasado y te asombras de lo que ha sucedido?

Ratliff: Sí, claro. Muchas cosas podrían haber sido diferentes. Recuerdo perfectamente el miedo y la ansiedad que sentía cada vez que salía un producto nuevo. En la época de Vulcan, una noche estaba trabajando hasta tarde cuando un tipo me llamó y me preguntó: "¿Has oído hablar de DataStar?". Le dije que no. "Un anuncio a página completa", me dijo, "un producto de MicroPro". En aquel entonces había vendido treinta o cuarenta Vulcans. Pensé: "Estuvo bien mientras duró, pero ahora se acabó, porque no puedo competir con sus recursos". Me desanimé mucho, pero al cabo de un tiempo se me pasó. Luego vino InfoStar. MicroPro solucionó sus problemas con DataStar: una gran campaña publicitaria, un gran anuncio por aquí, un gran anuncio por allá, y pensé: "Bueno, da igual". Lo mismo me pasó con Knowledge Man. Cuando salió Knowledge Man, estaba a punto de alcanzar algunas metas que me había propuesto. Estaba casi al 60 o 70 por ciento del camino recorrido, y entonces pensé que algo nuevo iba a salir y acabar conmigo.

Cada vez me preocupaba menos. No me preocupó mucho R:base. Y me preocupa aún menos ANZA. No sirve de nada preocuparse; lo que tenga que pasar, pasará.

Lammers: ¿Ya has visto Paradox?

Ratliff: No, no he visto ninguno de los productos de la competencia. La semana pasada, en una fiesta, estuve hablando con Eric Kim y Dave Hull del departamento de Marketing, y me preguntaron qué opinaba de Paradox. Les dije que no lo conocía. "¿Cómo? ¿No lo has visto?", preguntaron. Les respondí: "Nunca he visto ninguno de estos productos; ni siquiera he visto R:base 4000". "¿No has visto R:base 4000?", insistieron. Repasamos el historial y todos los demás productos que no conocía. No podían creer que no los hubiera visto, que no los hubiera probado ni que no hubiera sacado ideas de ellos.

Lammers: ¿En qué estás trabajando actualmente?

Ratliff: Últimamente he estado trabajando en un paquete de dominio público que he transcrito de Pascal a C. Es un lenguaje de diseño y documentación, una especie de clon o superconjunto de PDL (Program Design Language), propuesto por Caine, Farber y Gordon en Pasadena. Es interesante porque se siente como escribir un programa, pero en realidad no se ejecuta en el ordenador. Es una forma de realizar especificaciones y diseño.

Lammers: ¿Qué consejo le darías a los jóvenes programadores de hoy?

Ratliff: Si alguien quiere programar, le resultará fácil. Si no quiere, por mucho que lo intente, en el mejor de los casos será difícil. Lo más probable es que se desilusione. Así que mi consejo es: haz lo que quieras.

He visto personas que no tenían ninguna relación con la programación o la informática y que se adentraron en ella y les gustó. Se engancharon enseguida y captaron la esencia del tema rápidamente. También he visto a otras personas que intentaron involucrarse a la fuerza, pero no lo consiguieron.

Lammers: ¿Cuál es la magia? ¿Qué crees que atrae a alguien al corazón de todo esto?

Ratliff: Bueno, es una combinación de varias cosas. Solía ​​jugar a un juego mental y preguntarme: ¿qué sería si hubiera nacido cien años antes? No lo sé, pero una posibilidad es detective, porque hay mucho trabajo de investigación en la programación, sobre todo en la depuración. Se trabaja con pistas, indicios. Una de las ventajas de la programación es que se trabaja con la realidad, mientras que en el trabajo de detective real, muchas veces no se obtiene una respuesta. En programación, solo se necesita esfuerzo. Siempre se puede encontrar la respuesta si se trabaja lo suficiente. Me considero un generalista y creo que, para lo que he hecho, eso fue importante. Hay mejores programadores que yo, mejores depuradores y diseñadores y mejores en todo. No puedo repetir en público exactamente lo que me dijo una vez un sargento instructor, pero en esencia era: "Soy un aprendiz de todo y maestro de nada".

---

Susan Lammers es presidenta y fundadora de Headbone Interactive, empresa que desarrolla contenido original para internet, televisión y otros medios. Susan es pionera en el ámbito multimedia. Lideró los primeros esfuerzos de Microsoft como editora asociada y directora de publicación multimedia en la División Multimedia, y fue responsable de los primeros títulos de medios interactivos de la compañía. Entre los proyectos bajo su supervisión se incluyen Encarta y Microsoft Bookshelf.

Source: http://www.foxprohistory.org/interview_wayne_ratliff.htm

Original: http://web.archive.org/web/20010414114758/http://www.rjh.org.uk/PAW/m1108.htm