Scott Guthrie es director general de la División de desarrollo de Microsoft. Dirige los equipos de desarrollo que crean CLR (Common Language Runtime), ASP.NET, WPF (Windows Presentation Foundation), "WPF/E", Windows Forms, IIS (Internet Information Services) 7.0, Commerce Server, .NET Compact Framework y las herramientas de desarrollo web y cliente de Visual Studio. Como parte de la nueva serie Perfil de Architecture Journal, Ron Jacobs se sentó con Scott para preguntarle acerca de su carrera y pensamientos con respecto a la arquitectura. (Haga clic aquí para consultar la carrera de Scott en Microsoft.)

RJ: Hoy hablaremos sobre usted y su carrera a aquellos que piensan: "Parece un trabajo ideal". ¿Cuál es su función en Microsoft?

SG: Dirijo nuestro grupo de plataforma de desarrollo .NET. Este grupo incluye CLR (Common Language Runtime), .NET Compact Framework, IIS (Internet Information Services), ASP.NET, Atlas, Commerce Server, Windows Presentation Foundation, Windows Forms y nuestras herramientas de desarrollo para aplicaciones web en Visual Studio.

RJ: Vaya... es mucho lo que abarca.

SG: Sí, es muy divertido... Comprende nuestros modelos de aplicación principales, el tiempo de ejecución, las herramientas y todos los motores sobre los que se ejecutan. Es mucho material fresco y mucho con lo que jugar.

RJ: La mayoría de las personas le recordarán por su asociación con ASP.NET. Volvamos a sus primeros tiempos aquí en Microsoft. ¿Cómo empezó?

SG: Comencé en el equipo de ISS allá por 1996 o 1997, trabajando en las tecnologías principales de servidor web y me vi envuelto en el lanzamiento al mercado de una versión de IIS. Después de lanzar IIS 4, empezamos a considerar las piezas del modelo de programación de la siguiente generación. En ese momento pensamos: "Quizá hayamos terminado. ¿Hay algo más que se pueda hacer en términos de conjuntos de características?".

Empezamos a hablar con muchos clientes y observamos detenidamente los tipos de aplicaciones que creaban. Nos dimos cuenta rápidamente de que había todavía mucho por hacer. El código y la separación de contenidos creaba muchos problemas, así como la manera de escribir código. Solíamos bromear diciendo que se producía código que se escribiría una vez pero nunca se leería. Desde una perspectiva centrada en las herramientas y la administración, el hecho de que nuestra infraestructura existente funcionara realmente bien suponía muchos retos. Para hacer que ocurriera, formamos un pequeño equipo para reflexionar acerca de futuras arquitecturas con IIS. Y ese equipo es el que inventó el controlador del núcleo HTTP.SYS que introdujimos con Windows Server 2003. Con un colega, empecé a contemplar las piezas del modelo de programación web y escribí el prototipo inicial de lo que llegó a ser ASP.NET.

RJ: Parece que estaba pensando en llevar esto al siguiente nivel y aprovechar algo súper secreto en aquellos tiempos. Recuerdo esos días de. NET; entonces usted solía llamarlo ASP+.

SG: Originalmente lo llamamos XSP; la gente siempre se preguntaba qué significaba la X. En ese momento, realmente no significaba nada. El XML comenzó así, al igual que el XSLT. Todo lo mejor parece empezar con una X, así que ese es el motivo por el que originalmente lo llamamos así. Durante los primeros seis meses, no usamos .NET. El CLR no existía (estaba comenzando al tiempo que nosotros), así que realizábamos la mayor parte de nuestra labor de creación de prototipos en C++, JavaScript y motores de secuencias de comandos de ActiveScript. Supimos que queríamos un entorno orientado a objetos y nos gustaron realmente las características del modelo de programación administrado en términos de recopilación de elementos no usados, de encapsulación y de técnicas de orientación a objetos. No obstante, en realidad comenzamos escribiendo el código de producción en C++, porque en ese momento no teníamos una buena plataforma de tiempo de ejecución en la que construir. Llevábamos unas dos semanas con ello cuando quedamos con el equipo de CLR; entonces ese equipo no tenía socios dentro de la compañía que creaba sobre su material. El único compilador que tenían era ese llamado "simple managed C" (C simple administrado), que llamábamos cariñosamente "bofetón". Acabamos diciendo: "Puede que debamos crear sobre esto". Supuso un riesgo inmenso y, en ese momento, nuestro equipo estaba compuesto por tres o cuatro personas en total. Se nos permitió apostar por ello principalmente porque a nadie le importaba si fallaba. Por fortuna, lo hicimos y dio un gran resultado. El resto es historia, por así decirlo.

RJ: Recuerdo esos tiempos. En los comienzos de CLR, pocas personas estaban dispuestas a apostar por ello. Muchos equipos dijeron: "Creo que no..."; pero sus chicos lo hicieron y obtuvieron un maravilloso resultado.

SG: Sí, la gente estaba aterrorizada con la idea de la recopilación de elementos no usados en el servidor, algo que hoy damos por sentado. En ocasiones me dijeron: "No hay manera de que puedas construir una aplicación con recopilación de elementos no usados en segundo plano. El servidor nunca escalará". Había muchas situaciones poco halagüeñas. Desde una perspectiva de proyecto, una de las cosas que hicimos dio un estupendo resultado. Nos dijimos: "Apostaremos por el código administrado y no se tratará de un simple contenedor del material nativo. Lo vamos a incrustar en la plataforma. Escribiremos aproximadamente el 95 por ciento del código en código administrado".

Teníamos dos motivos para hacerlo de ese modo. Uno era para aprovechar totalmente la extensibilidad que ofrecía e incrustar la extensibilidad orientada a objetos muy profundamente en la plataforma. Y el segundo era que sabíamos que esas aplicaciones cliente estarían escritas en código administrado y que nuestro porcentaje de código en una pila de llamada sería relativamente pequeño en comparación con el recurso compartido del cliente. Si incluso nosotros no pensábamos que podríamos escribir en código administrado, nos estábamos engañando al pensar que las aplicaciones funcionarían. Se trató de una gran función forzada. Desde el primer día y mientras creábamos muestras más complicadas, estábamos preparando el motor CLR principal y eso se tradujo en inmensos ahorros para el cliente cuando empezamos a crear aplicaciones cliente más complicadas sobre él. Fue una buena apuesta.

RJ: Resulta interesante que lo tome como una forma de aplicar mejoras al motor. Usted dijo: "No sólo lo estamos haciendo, sino que estamos mejorando el motor al hacerlo".

SG: Creo que se trató de una gran apuesta, pero fue un enfoque que funcionó bien. El hecho de que fuéramos un equipo pequeño y que comenzáramos con una base de código nueva, ayudó tremendamente. Si hubiéramos sido un equipo más grande o tendido una base de código heredado existente de grandes dimensiones, habría sido más difícil, porque la interoperabilidad COM no existía en aquellos tiempos. Pero, el hecho de que empezábamos desde cero y éramos capaces de comenzar con algo pequeño, ayudó realmente a llevar esas mejoras directamente al motor. Cuando crecimos y nuestro conjunto de características salió a la luz, no hizo más que rendir dividendos.

RJ: Creo que es estupendo que la gente que le dirigía le permitiera tomar ese camino.

SG: Se trataba definitivamente de una apuesta, pero de una bien calculada. Existían muchas ventajas si lo hacíamos funcionar, pero la desventaja consistía en que éramos tres o cuatro y siempre podríamos hacer algo nuevo el siguiente año. A menudo, Microsoft ha hecho estas grandes apuestas y generalmente sale ganando. En ocasiones no ocurre así (pueden cometerse numerosos errores), pero, como empresa, tratamos de asegurarnos de apostar a lo grande en un par de asuntos clave.

RJ: ¿Tuvo que persuadir a alguien para que le permitiera asumir ese riesgo o fue más sencillo?

SG: Ciertamente, tuvimos que persuadir a varias personas en el camino. Algo que hicimos pronto en el desarrollo del proyecto fue obtener código en ejecución en prototipos que se pudieran mostrar. A menudo, cuando se trabaja en un proyecto nuevo o en algo que no se ha hecho antes, es fácil reunir unas cuantas diapositivas de PowerPoint que suenen bien, pero resulta especialmente valioso mostrar código real y enseñarle a la gente el código en ejecución. El prototipo no sólo demuestra que se trata de algo real, sino que también se aprende muchísimo al hacerlo.

Una de las cosas que trato de hacer con mi equipo es llevar a cabo prototipos pronto, crear aplicaciones de muestra pronto, especialmente aplicaciones de demostración que podamos mostrar al cliente para decirle: "Mire, así es como puede crear una aplicación". Tratamos de hacerlo lo antes posible para averiguar qué funciona y qué no, de modo que podamos reaccionar de forma consecuente. Aproximadamente cuando llevábamos un mes y medio en el proyecto de ASP, escribí un prototipo y pudimos mostrarlo. Se incluía el modelo de componentes mediante controles (entonces no los llamábamos controles, se trataba de etiquetas declarativas o componentes) y la manera controlada por eventos de programar para Internet. Pudimos construir aplicaciones y descubrimos rápidamente que algunas de las cosas que habíamos propuesto eran realmente imposibles de codificar. Al mismo tiempo, vimos que "sería estupendo tener esta característica o esa característica" y repetimos durante el camino. Eso ayudó tremendamente al tratar de hacer que la gente se diera cuenta de que no estábamos del todo locos. Pudimos mostrar código y ellos pudieron obtenerlo. De todas formas, se trataba de una apuesta.

RJ: Casi suena como una actitud de desarrollo mediante pruebas. Hagamos repeticiones cortas; obtengamos algo que funcione. Probaremos nuestro propio material y escribiremos contra nuestras propias API para entender lo que se siente al usarlas.

SG: Es definitivamente el mismo tipo de principio. Distingo entre el desarrollo mediante pruebas como una metodología para alcanzar pronto la calidad y ofrecer una base que permita refactorizar y adaptar la base de código sin tener que preocuparse por las regresiones. Ciertamente seguimos esa filosofía de forma interna cuando desarrollamos el código de producción. Creo que también tiene valor el hecho de llevar a cabo una fase de prototipo incluso antes de obtener el código de producción. Se trata de uno de los éxitos que conseguimos con ASP.NET. Dijimos que íbamos a desechar todas las líneas de código que escribiéramos en el siguiente par de meses. Nos pusimos de acuerdo en ello. No íbamos a decir: "Oh, tomemos esto y adaptémoslo, podemos limpiarlo". No. Lo íbamos a desechar. Borraríamos este subdirectorio y así podríamos aventurarnos con cosas nuevas. No tendríamos que preocuparnos por asegurarnos de que todo era estable, porque estaría en la versión final.

Realmente lo hicimos durante unos meses y nos dijimos: "Hemos terminado, borrémoslo y empecemos desde cero; ahora escribiremos el código de producción y nos aseguraremos de incluir calidad a la vez". Creo que muchos equipos podrían beneficiarse de ese proceso. Lo más duro es asegurarse de borrar el código del prototipo. Con demasiada frecuencia, los proyectos se desarrollan con un "bueno, se aproxima a lo que se esperaba". Es muy difícil empezar con un prototipo y hacerlo estable. Creo firmemente en que se debe comenzar con una fase de prototipo para después eliminarlo.

RJ: Este hecho demuestra que valoramos el aprendizaje más que estos archivos y bits de la fase de prototipo.

SG: Cada vez que se trabaja en un proyecto, si se vuelve a escribir algo, tanto si se empieza desde cero como si no, el código mejora. En parte, se debe a que se comprenden los problemas y trampas del último enfoque y se pueden reflejar, a la vez que se mejora. El desafío consiste en que no se puede hacer con frecuencia. Pero, cuando se empieza con un proyecto o una nueva área donde no está claro cómo llegar del punto A al producto terminado, resulta tremendamente valioso el hecho de contar con un periodo dedicado al prototipo y a hacer pruebas.

RJ: Algunas personas lo llaman "pico arquitectónico". Se trata de una nueva área que vamos a explorar. Cambiando de tema, ¿qué hacía antes de venir a Microsoft?

SG: En realidad, me uní a Microsoft nada más terminar los estudios. Hice prácticas en Microsoft mientras estudiaba. Mientras estaba en la facultad y el instituto, participé en un par de fases de inicio, llevé a cabo algunos desarrollos y me divertí, pero me uní a Microsoft justo al terminar los estudios.

RJ: Hemos estado hablando a muchas personas a las que les interesa la arquitectura. Parece que hay pocos arquitectos puros, que sólo diseñen y nunca escriban código. La mayoría de la gente es una mezcla: dedican tiempo al desarrollo y también a la arquitectura. ¿Qué consejo daría a alguien que ha estado desarrollando pero quiere dedicarse más a la arquitectura?

SG: El hecho de escribir código resulta valioso para los arquitectos. No se trata necesariamente de proteger el código de producción, sino probar constantemente nuevas tecnologías, enfoques y comprobar cómo funciona el sistema. No escribo mucho código de producción hoy en día, pero paso una hora o dos al día haciéndolo. Puede tratarse de muestras, prototipos o algún proyecto personal divertido (cualquiera lo es, pruebo cosas, pensando en maneras de estructurarlas). La práctica es muy valiosa desde una perspectiva de arquitectura de código.

También recomendaría echar un vistazo a la teoría principal de sistemas y a cómo diseñar arquitecturas de sistemas muy estables. Hay que tener en cuenta algunos de los principios sobre los que se desea reflexionar y aplicarlos a lo que se está llevando a cabo. Eso no significa que se deba pensar cómo deben ser las líneas de código, sino en la sencillez, estabilidad o tolerancia a los errores. Ese tipo de cosas son básicas para contar con un sistema satisfactorio; tanto si se trata de una aplicación cliente, como si es una aplicación de servidor o un juego. Un arquitecto que piensa constantemente en esa clase de principios y los puede unir a un buen fondo de codificación, puede ofrecer una tremenda orientación a los equipos.

Esos principios no tratan de la reproducción de un asistente ni obtener materiales nuevos y estupendos, sino del estudio del funcionamiento del espacio de direcciones de procesos de aplicaciones Windows o UNIX. ¿Qué es lo que lo une y cómo se interioriza profundamente su apariencia en un sistema de multiprocesador o multinúcleo? Se trata de absorber ese tipo de conocimiento, reflexionando acerca de sus ramificaciones y las tendencias, hacia dónde va la tecnología desde una perspectiva de hardware y software y tener en cuenta el modo de adaptarlo y aprovecharlo. Eso es lo que recomiendo que se haga.

RJ: En Microsoft tenemos desarrolladores, directores de programa y arquitectos. La gente a menudo tiene curiosidad acerca de la función del arquitecto. ¿Cuál espera que sea la función del arquitecto en el equipo?

SG: Hay un par de responsabilidades que esperamos que los arquitectos aporten al equipo. La primera es una muy profunda y sólida experiencia en arquitectura, desarrollo y los principios de software de los que hablaba. Con ese tipo de perfil, esperamos que tenga lugar un proceso de ósmosis: que algo de estos conocimientos se transmita a otros miembros del equipo. Las conversaciones en el pasillo o las charlas informales de oficina pueden ofrecer una cantidad tremenda de liderazgo a un equipo, especialmente cuando se supervisa a los desarrolladores con mayor y menor experiencia.

Esperamos que un arquitecto prepare el terreno con respecto a lo que el producto debe hacer desde una perspectiva técnica. A menudo, los arquitectos llevan a cabo unas tareas más avanzadas de desarrollo de prototipos e investigación acerca de a dónde deberíamos llevar el producto. Esperamos que nos recomienden qué camino debemos seguir y, desde la perspectiva de la implementación, les pedimos que observen tanto el producto de la siguiente generación como el actual para identificar las áreas que debemos limpiar. Por ejemplo, ¿qué áreas debemos abordar de forma ligeramente distinta? ¿Qué prácticas podemos implementar a través de la base de código para mejorarlo?

RJ: Además de habilidades técnicas profundas y sólidas, ¿qué otros atributos piensa que contribuyen a que un arquitecto sea el adecuado?

SG: Lo más duro, al menos en Microsoft, es que las personas profundamente técnicas que quieren ascender por el camino arquitectónico deben asegurarse de que pueden fundir sus habilidades técnicas con la posibilidad de trabajar tanto en un equipo como en varios equipos de la empresa.

Algunas de esas habilidades sociales son más difíciles de adquirir, lo que significa que el arquitecto debe ser práctico, pero de manera que no asuste a los desarrolladores o al resto de equipos. También, deben evitar las conversaciones del tipo "yo tengo esto, tú tienes aquello". Los arquitectos deben poder trabajar en varios equipos de forma muy flexible. Deben hacerlo de manera que hagan que la gente sienta que los arquitectos se ocupan de los problemas más interesantes en un momento y luego huyen cuando las cosas se ponen difíciles. Los otros miembros del equipo tienen que creer que el arquitecto se dedica al equipo y forma parte de una relación a largo plazo que ofrece resultados con respecto a un problema. Ese es el tipo de habilidades que un arquitecto debe desarrollar. Los arquitectos con mucha experiencia y con mayor repercusión pueden aunar habilidades muy técnicas y de diseño con las habilidades colaboradoras y sociales.

RJ: Muchas personas me dicen que la tasa de cambio se acelera y se lanza nuevo material constantemente. Mencionó cuán importante es estar al día a este respecto, pero prácticamente no hay tiempo suficiente. ¿Cómo se mantiene usted al día?

SG: Es difícil, especialmente en lo referente al desarrollo. Cuando pienso en el ritmo de innovación en proceso en este mismo momento y la tasa del flujo de información, ciertamente no recuerdo un momento en el que haya ido así de rápido. Echo la vista a atrás, las batallas de Internet de los años 90, cuando Internet Explorer competía con Netscape. En ese tiempo, sentíamos que lanzábamos productos al mercado constantemente y que había muchos proyectos en marcha.

Desde la perspectiva del desarrollo, creo que nos encontramos en una fase en la que el ritmo está aún más acelerado que entonces. Ciertamente, resulta muy complicado mantenerse al día. Hay que encontrar tiempo para hacerlo. Se debe estar pendiente de lo que sucede. Creo que los blogs son un gran mecanismo para hacerlo. Estoy suscrito a Bloglines, un gran servicio gratuito. Posiblemente estoy suscrito a 300 ó 400 blogs y trato de pasar de 20 a 30 minutos al día por la mañana y por la tarde leyendo lo que allí se escribe. Te da una buena perspectiva de los temas de actualidad y las ideas más interesantes.

Parte del hecho de mantenerse al día significa pasar una hora al día desarrollando prototipos; probando cosas, bien tu propio producto u otras tecnologías; obtener una visión de las piezas de las que se dispone y cómo usarlas. La otra tarea importante, cuando se estudia cualquier nueva tecnología, API o enfoque de programación, es reflexionar no sólo sobre lo propiamente interesante, sino también intentar extrapolar sus principios útiles para aplicarlos a otros proyectos. De este modo, si se trata de un libro de refactorización de Java, estupendo. Tiene algunas refactorizaciones específicas de Java, pero ¿qué conceptos de refactorización más amplios se pueden interiorizar y aplicar a VB o C#? Si es un marco de JavaScript de AJAX muy bueno para llevar a cabo una tarea específica, genial. Ahora, vuelve a atrás e intenta reconocer cuál de estos aspectos se podrían aplicar a otro marco JavaScript. Un arquitecto debe saber ver algo y extrapolar los aspectos interesantes de ello o derivados, en comparación con el elemento individual de la tecnología.

RJ: Cuando echa la vista a atrás y recuerda su paso por MS, ¿se arrepiente de algo?

SG: Al mirar hacia atrás, hay cosas que uno haría de forma distinta. A veces, puede tratarse de alguna decisión técnica, la forma de implementar una característica y piensas: "Todos abusan de esa característica". O las cosas no se hacen exactamente de la manera en la que pretendíamos que se hicieran. Sin duda, al haber creado una plataforma de desarrollo tan amplia como .NET, podría proponer una docena de cosas que, en retrospectiva, me gustaría que se hubieran hecho de forma ligeramente distinta. Hay también maneras de enfocar los asuntos o maneras de trabajar con distintos equipos y pensar: "Cielos, ojalá hubiera llevado esa conversación de forma diferente". Así que hay definitivamente multitud de ejemplos individuales que podría plantear.

En términos generales, me agrada el punto en el que se halla .NET, ha sido bastante satisfactorio el lugar al que lo hemos llevado. Pero hay muchas cosas que me gustaría que hubiésemos hecho de distinta manera, como "Cielos, ojalá no hubiésemos sellado esa clase" o "Vaya, ojalá no hubiésemos desellado esa clase".

De haber algo significativo que deseara haber hecho de otra forma, sería haber dedicado más tiempo en las primeras fases a reflexionar acerca del proceso de instalación cliente para crear aplicaciones cliente .NET. Creo que el enfoque que tomamos con un solo redistribuible descargable no es peor que cualquier otro redistribuible de Windows, pero desearía haber aprovechado la oportunidad antes para obtener una instalación menos impactante y simplificar la implementación de la aplicación cliente. Se trata de algo en lo que empleamos mucho tiempo actualmente y va a ser muchísimo mejor en el futuro, pero me gustaría que lo hubiésemos hecho hace seis años y haber dedicado más tiempo a pensar en esas situaciones algo antes.

RJ: En su oficina guarda muchas acreditaciones de conferenciante y ha tenido la oportunidad de ir a muchos lugares y conocer a mucha gente. ¿Cuáles son sus momentos más reseñables? ¿Hay alguien que destacable que se le venga a la mente?

SG: Una de las cosas divertidas de trabajar en una plataforma de desarrollador es ver la gama y diversidad de aplicaciones que la gente ha creado con nuestro material. Tanto si se trata de MySpace, que es la mayor plataforma de red social del mundo (se ven mil millones y medio de páginas al día con .NET), como si es la Bolsa de Londres o el servicio nacional de sanidad del Reino Unido o varias empresas de Wall Street, Costco, Dell.com o Match.com, hay miles de estupendas aplicaciones cliente creadas con la tecnología de Microsoft. Muchas de ellas están en Internet; otras usan una tecnología distinta. Si vas a las propiedades de Walt Disney World, las máquinas que expiden las entradas Fast Pass funcionan con Compact Framework y CLR. Si alguien llama a la puerta del censo de EE.UU o su servicio postal, el dispositivo que esa persona presiona también ejecuta .NET Framework.

Ese, para mí, es el punto más reseñable: ver cómo .NET se usa por todas partes. A veces de formas raras y disparatadas, otras veces en aplicaciones críticas, pero siempre de un modo único en el que, francamente, no habías pensado. Creo que el sello de un buen marco no reside en las aplicaciones que la gente crea en él y que esperas que creen, sino en el hecho de que los clientes y desarrolladores pudieron llevarlo mucho más allá de lo que te habías imaginado. Para mí, ése es el punto culminante de .NET.

Carrera de Scott Guthrie en Microsoft

Scott Guthrie se unió a Microsoft en 1997 y primero trabajó en IIS4 y el Windows NT Option Pack. Poco después, diseñó y desarrolló el prototipo de un nuevo modelo de programación de servidores cuyo nombre en clave original era "XSP" y, junto con Mark Anders, formó como consecuencia un nuevo equipo en 1998 para construir lo que finalmente se llamó ASP.NET.

Scott se convirtió en director de unidad de producción (PUM) del equipo de ASP.NET a principios de 2002 y lanzó ASP.NET V1.1 como parte de Windows Server 2003. Durante ese tiempo, también dirigió la incubación de la popular herramienta de desarrollo web Matrix, una herramienta de desarrollo de ASP.NET gratuita que ayudó a propiciar nuevas formas de pensar acerca de las herramientas de desarrollo web, así como un enfoque nuevo de dirigirse a los aficionados y entusiastas de la programación. A finales de 2002, también paso a ser PUM de las características de las herramientas web de Visual Studio y era responsable del producto independiente Visual Web Developer, que se lanzará al mercado como parte de la familia Visual Studio 2005, así como las características de desarrollo web de Visual Studio. Visual Web Developer y ASP.NET 2.0 introdujeron su primera versión beta pública generalizada en el verano de 2004 y saldrán al mercado en la primera mitad de 2007.

A finales de 2003, el equipo de Scott se unió al equipo de IIS y él se convirtió en PUM de un equipo de herramientas y plataforma web unificado que combina las ventajas de IIS, ASP.NET y Visual Studio. De forma simultánea a la finalización de ASP.NET 2.0 y Visual Web Developer, el equipo desarrolla activamente la siguiente versión de Web Application Server de Microsoft, que se lanzará al mercado como parte de Longhorn.

Scott Guthrie, actual director general de la División de desarrollo de Microsoft, dirige los equipos de desarrollo que crean CLR, ASP.NET, WPF, "WPF/E," Windows Forms, IIS 7,0, Commerce Server, .NET Compact Framework y las herramientas de desarrollo web y cliente de Visual Studio.

Scott obtuvo el título de Informática en la Duke University en 1997.