Software con opinión
En el desarrollo de software tener muchas opciones entre las que elegir puede ser algo positivo, sin embargo a veces tener demasiadas opciones también puede ser un problema.
Pensemos, por ejemplo, en los frameworks de javascript. Existen docenas de ellos: jQuery, Prototype, Yahoo UI, Dojo, ExtJs, GWT, MooTools… Todos son buenos y elegir la mejor opción es algo muy complicado: para encontrarla deberíamos pasar un tiempo considerable evaluando cada uno de ellos, sus ventajas y sus inconvenientes, y como solucionan los problemas que tenemos.
Pero, ¿merece la pena tanto esfuerzo? Probablemente no. Aunque haya un framework que sea inherentemente mejor que los demás, vamos a perder más tiempo buscándolo y evaluando posibles opciones, que si utilizásemos directamente el segundo o el tercer mejor framework, porque, entre los más conocidos todos son suficientemente buenos.
En mi opinión, la mejor solución para este problema es la que toma Ruby on Rails. Rails es Opinionated Software, software con opinión. Cuando creamos una aplicación nueva con Rails, la aplicación viene ya “con las pilas incluidas”: ya tiene un framework javascript -prototype- una librería de testing, librería para fixtures , un motor de plantillas, un librería de ORM; la aplicación ya tiene una estructura: los controladores van en este directorio, las vistas en este otro; Rails utiliza Convention Over Configuration para darle nombre a las tablas en la base de datos, a las vistas y a los controladores; todas las tablas utilizan como clave principal un id autonumérico. Nada más empezar, el equipo de Rails ya ha tomado un montón de decisiones difíciles por ti.
Todas estas decisiones son discutibles, pero en la práctica resulta que en la inmensa mayoría de los casos, las decisiones que ha tomado el equipo de rails son suficientemente buenas. Rails es software con opinión, dice: yo hago las cosas así. Si luego quieres cambiar cualquier cosa, puedes hacerlo. Ruby es un lenguaje tan dinámico que eso no suele ser problema: aunque rails venga, por ejemplo, con su ORM -ActiveRecord- o su motor de plantillas -ERB-, se puede sustituir ActiveRecord por DataMapper o ERB por Haml. Yo, por ejemplo, cuando programo con Rails suelo utilizar jQuery en vez de Prototype, el framework javasacript que trae Rails por defecto.
Si lo hago es porque tengo claro lo que quiero y sé lo que estoy haciendo. Pero si no lo tienes claro, Rails ya te da un stack que funciona muy bien y te ahorrará muchas indecisiones y quebraderos de cabeza.
Parálisis por análisis
Cuentan la historia de un burro que murió de hambre porque le pusieron delante un cubo de alfalfa y otro de cebada y no supo por cuál decidirse.
Siempre pensamos que tener muchas opciones disponibles es algo inherentemente bueno, una ventaja en cualquier situación. Tener muchas opciones puede ser algo conveniente en ciertas circunstancias, pero también puede conducir a lo que se conoce como parálisis por análisis.
Para estudiar cómo tomamos decisiones complejas, los investigadores Eldar Shafir y Donald Redelmeie dieron a un grupo de médicos el historial hipotético de un paciente de 67 años que sufría de dolor crónico de cadera. El paciente llevaba años de tratamiento con distintos medicamentos que no le habían solucionado su problema, por lo que los doctores se estaban planteando una operación de sustitución de cadera. Esta operación es muy traumática y tiene una recuperación larga y complicada por lo que sólo está indicada en casos los que otras terapias ya han fracasado.
Sin embargo, justo antes de que el paciente se sometiese a la operación, los doctores descubrieron que había un medicamento que no se había probado con el paciente y que podría ayudarle. Ante este historial, el 47% de los doctores optaron por el procedimiento menos agresivo de recurrir a la cirugía si este último medicamento tampoco surtía efecto.
Sin embargo, cuando los investigadores cambiaron la historia para que no sólo quedase un medicamento por probar, sino dos, sólo el 28% de los doctores se decantaron por probar con los medicamentos.
El sentido común nos dice que hay más posibilidades de que cualquiera de los dos medicamentos ayude al paciente, pero este factor no parece determinante en la decisión de los doctores. ¿Qué está pasando?
Cuando nos enfrentamos a una decisión complicada, cuantas más opciones tengamos, más confuso se vuelve el asunto y más difícil es decidirse. Al final, llegamos a una situación de confusión en la que ninguna opción parece claramente mejor, cuanto más analizamos el asunto más difícil resulta tomar una decisión. Sufrimos lo que se conoce parálisis por análisis, una parálisis que nos impide tomar ninguna decisión. En esa situación, suele ganar la ley de la inercia: lo más fácil es no tomar ninguna decisión y que las cosas sigan como estaban.
La fuerza de voluntad es un recurso finito
A menudo pensamos que existe gente con una gran fuerza de voluntad y otros que simplemente son vagos y perezosos. Y esto es así, pero también lo que parece vagancia puede ser, a veces, simple agotamiento.
En 1998 un grupo de investigadores americanos realizaron una serie de experimentos destinados a medir cómo el ser humano hace uso de su fuerza de voluntad. En los experimentos se citaba a un grupo de estudiantes universitarios para participar en un supuesto estudio sobre la percepción del sabor. Los investigadores pidieron a los estudiantes que se saltaran una comida antes del estudio y que no comieran nada en las tres horas anteriores al experimento para asegurarse de que tenían hambre.
Justo antes de que llegaran los conejillos de indias, los investigadores cocinaron en la sala contigua al estudio una remesa de galletas que inundó el ambiente de aroma a chocolate. Cuando los estudiantes llegaron se les sentó en una sala, llena de ese delicioso aroma a chocolate, en la que había una mesa con dos fuentes: una llena de galletas recién horneadas y la otra llena de rábanos. Los investigadores intentaban poner a prueba la fuerza de voluntad de los sujetos: les pidieron a la mitad que comieran galletas de chocolate y a la otra mitad que comieran rábanos. Además, dejaron solos a los sujetos para favorecer la tentación de comer galletas de chocolate.
En principio, parecía que todo el montaje había sido en vano porque ninguno de los desgraciados comedores de rábanos sucumbió a la tentación y se comió una galleta prohibida. Sin embargo, lo que ocurrió poco después demuestra que la tentación de las galletas sí que dejó huella en los comedores de rábanos.
Después unos minutos saboreando la comida que les había caído en suerte -rábanos o galletas- los investigadores proporcionaron a los estudiantes un par de cuestionarios. Cuando los estudiantes terminaron de responder, los investigadores dieron por finalizado el experimento y dieron paso a un nuevo estudio sobre la capacidad cognitiva de los estudiantes. Este experimento consistía en pedir a los estudiantes que resolvieran varios puzzles complicados, trazando una serie de figuras geométricas sin levantar el lápiz de papel. Les dijeron a los estudiantes que no importaba cuanto tiempo tardasen en resolver el puzzle ni el número de intentos que empleasen.
El único problema es que esos puzzles no tenían solución posible: los investigadores simplemente medían la perseverancia de los sujetos. Y en ese test sí que se observó una gran diferencia entre los comedores de galletas y los comedores de rábanos: los comedores de galletas estuvieron intentando resolver el puzzle una media de 19 minutos, e hicieron por término medio 34 intentos. Sin embargo, los comedores de rábanos sólo emplearon una media de 8 minutos y 19 intentos.
Los investigadores eligieron a los comedores de rábanos al azar, no eran gente menos perseverante o motivada que sus compañeros comedores de galletas. Y, sin embargo, perseveraron mucho menos en resolver el puzzle. ¿Por qué? Por lo que se conoce como agotamiento del ego: Podemos emplear la fuerza de voluntad para resistir nuestros impulsos, pero esta capacidad de esfuerzo es finita y se agota si la forzamos demasiado. Nuestra fuerza de voluntad es finita. Usadla para algo positivo.
El programador políglota
Cada vez que programadores que provienen de distintos entornos se juntan para crear un nuevo proyecto surge la cuestión de qué lenguaje se va a utilizar, a la que suele seguir el inevitable flamewar sobre qué lenguaje es mejor. En seguida aparecen los viejos tópicos: java es lento, php sólo sirve para hacer aplicaciones sencillas, ruby no escala, erlang… ¿qué es eso de erlang?, etcétera.
Estas discusiones rara vez llegan a un resultado provechoso, y no sólo porque los argumentos utilizados muchas veces no tienen ningún fundamento, sino porque la pregunta -¿qué lenguaje es mejor?- está mal planteada: Los lenguajes no suelen ser mejores o peores por sí mismos, sino solamente más o menos adecuados para ciertas tareas.
Los lenguajes son herramientas. ¿Qué herramienta es mejor, un destornillador o una llave inglesa? Depende de si quieres atornillar un tornillo o enroscar una tuerca. Dice el proverbio chino: al que tiene un martillo todo le parecen clavos. Yo digo que antes de utilizar ese martillo para desenroscar una tuerca, el desarrollador debería plantearse si no habrá alguna herramienta más adecuada para lo que quiere hacer.
Nos guste o no, la realidad de la web nos ha enfrentado con el hecho de que un sólo lenguaje ya no basta. Antiguamente era posible hacer una aplicación de escritorio completa usando sólo C, C++ o Java. En cambio, para hacer una aplicación web medianamente decente, hay que conocer el lenguaje en el que se programe el backend -ya sea ruby, php, java o c#-, pero además es inevitable tener conocimientos de SQL, javascript, css, html… Eso como mínimo. Repito: en el mundo web un sólo lenguaje ya no nos basta.
Y este punto no sólo se aplica a la diferencia entre el backend y el frontend de una aplicación web que, al fin y al cabo, son ámbitos distintos y por lo tanto parece natural que utilicemos lenguajes distintos. También dentro del servidor puede tener sus ventajas que utilicemos varios lenguajes de programación.
Los entornos de ejecución modernos, como la máquina virtual de Java o el CLR de .NET, hacen que los distintos lenguajes puedan convivir y entenderse entre ellos. Por ejemplo, la máquina virtual de Java puede ejecutar código escrito en Java, Ruby, Scala, Groovy, Clojure, Python, PHP, Javascript, Ada, Cobol, etcétera. La lista es larga. Y no sólo eso: yo puedo utilizar JRuby, por ejemplo, para llamar a código escrito en Java o en Scala desde mi programa escrito en Ruby. Gracias a la máquina virtual, las barreras entre lenguajes son cada vez más pequeñas y Ruby puede entenderse perfectamente con Java.
Un ejemplo claro es el framework web Grails. Está pensado para utilizarse en Groovy, pero su núcleo está construido sobre Spring e Hibernate. Es decir, tenemos un framework web escrito en Groovy que se apoya en librerías escritas en Java. Y el resultado funciona muy bien.
En su libro The Productive Programmer, Neal Ford llama a este enfoque programación políglota. ¿Qué es la programación políglota? Muy sencillo: se trata de utilizar en cada momento el lenguaje más adecuado para la tarea que haya que llevar a cabo. El programador políglota es aquel que tiene en su repertorio gran cantidad de herramientas -lenguajes-, conoce bien sus puntos fuertes y sus limitaciones, y sabe qué herramienta hay que utilizar para cada tarea.
El modelo McDonalds y el modelo Google
En 1985 Michael Gerber escribió el libro The E-Myth donde explicaba el éxito de empresas como McDonald’s o Burger King. McDonald’s ha creado una receta para montar negocio muy rentable, que es repetible por cualquiera, y la ha comercializado en forma de franquicia. McDonald’s tiene éxito porque puedes ir a Torrelodones, a Münich o a Melbourne, pedir un Big Mac, y en los tres sitios obtendrás prácticamente el mismo producto.
Que un Big Mac sepa bien -o no, según el gusto- no depende de la pericia del cocinero. McDonald’s ha conseguido destilar la receta del Big Mac en una serie de pasos exactos que no dan lugar a fallo: la carne se compra aquí, se hace durante tantos segundos y los ingredientes de la salsa son estos. Todo está especificado al milímetro para que el cocinero sólo tenga que seguir unos pasos sencillos para hacer un Big Mac. Si mañana el cocinero se va a trabajar a otro sitio, no es ningún problema porque es fácil encontrar a otro que haga exactamente el mismo trabajo. Y los Big Macs seguirán sabiendo igual. En McDonald’s cualquiera es prescindible.
A gran parte del público no le gustan las sorpresas y ese el motivo de que McDonald’s tenga tanto éxito: puede que la comida no sea gran cosa, pero cuando vas, sabes exactamente lo que te espera. No hay sorpresas.
Las franquicias suelen emplear este modelo de negocio: empaquetar un negocio que funciona y es reproducible y venderlo a cambio de una parte de los beneficios. Es un negocio rentable que ha permitido a empresas como McDonald’s crecer hasta el infinito y más allá.
Pero lo que sirve para vender comida rápida no tiene por qué servir en otros campos como la informática. Pensemos, por ejemplo, en Google: Google no se dedica a contratar empleados para realizar un trabajo que podría hacer cualquiera, sino que hace justo lo contrario: contrata a gente muy especial, de la inmensa minoría más brillante y les encarga -o les permite crear- productos revolucionarios. Cualquiera no puede hacer un Gmail o un Google Maps, y si no fuera por el talento de gente como Paul Buchheit -el creador de GMail- o los hermanos Rasmussen -creadores de Google Maps y Google Wave- no existirían estos productos. El éxito de Google depende de que tenga trabajando en sus filas a las mentes más brillantes..
Google y McDonald’s son dos casos extremos, pero entre ellos hay un espectro continuo de empresas que valoran más o menos la iniciativa de sus empleados; más parecidas a Google o a McDonald’s.
En España, por ejemplo, no es raro ver consultoras que se empeñan en aplicar el modelo McDonald’s a la informática. Intentan crear un modelo de negocio basado en productos de baja calidad y en legiones de empleados, a los que pagan poco y forman menos, y que son completamente prescindibles. Dicen: vamos a desarrollar este core para que después las vistas, o los módulos, los jsp o lo que sea, se puedan hacer en una software factory. Es una manera de decir: vamos a hacer un producto que cualquiera pueda desarrollar, vamos a hacer que tus empleados sean prescindibles, vamos a inventar el BigMac-JSP.
Creo que en un campo como la informática, donde ser innovador es una ventaja enorme, esta estrategia tiene las patas muy cortas. Puede servir para crear productos chapuceros que funcionan si no eres demasiado exigente, pero nunca servirá para crear un producto de calidad. Así nunca se creará un producto memorable.
¿Qué es la deuda tecnológica?
¿Os habéis encontrado alguna vez con código mal escrito que es difícil de mantener y más difícil de reutilizar? Apuesto a que sí.
Ese código muchas veces no es chapucero porque el programador no sepa hacerlo mejor, sino porque se ha hecho con prisas y sin preocuparse en que ese código pueda extenderse con facilidad en el futuro. Se ahorra tiempo, por ejemplo, en técnicas como los test unitarios que mejoran considerablemente la calidad del código.
Cuando uno se ve forzado a trabajar con una base de código muy mal escrita, los proyectos acaban tardando mucho más de lo necesario. Lo que podíamos haber hecho en dos días acaba tardando diez. O cuarenta. Todo es mucho más complicado porque tenemos que enfrentarnos a las problemas que nos presenta el código legado.
Para explicar las consecuencias del código hecho con prisas Ward Cunningham acuñó el término deuda tecnológica. Hacer código de mala calidad a toda prisa, es como pedir un crédito: puede que obtengamos un beneficio a corto plazo pero si tenemos que seguir desarrollando ese código, tarde o temprano tendremos que pagar todo el tiempo que nos habíamos ahorrado y los intereses. Refactorizar código mal escrito es siempre más difícil que escribirlo bien desde el principio.
A veces la deuda tecnológica tiene sentido. Puede que tengamos que terminar un producto antes que un competidor, o puede que si no terminamos pronto perdamos una gran oportunidad de negocio. En ese caso, la deuda tecnológica tiene el mismo sentido que la deuda financiera: incurrimos en algo de deuda para obtener unos beneficios tan grandes que compensan de sobra el pago de los intereses.
Sin embargo, la deuda tecnológica, como la financiera, también tiene un aspecto muy peligroso: recurrir a la deuda es una manera muy sencilla de tapar los problemas que tiene nuestro negocio. Entra dinero y crea la ilusión de que el negocio sigue funcionando, aunque en realidad sólo hemos aplazado los problemas al tiempo que los empeoramos.
Con la deuda tecnológica pasa lo mismo. Hacer constantemente chapuzas puede dar la sensación de que los proyectos avanzan. Sin embargo, al poco tiempo acabamos con una maraña de código inmantenible; lo que debería ser muy sencillo se convierte en complicado y los desarrollos avanzan cada vez más despacio.
Es porque todo nuestro esfuerzo se invierte en pagar los intereses de la deuda tecnológica.
El sello que certifica que se está siguiendo el modelo en cascada es el documento de requisitos funcionales. El documento funcional especifica, antes que se empiece a programar, como debe ser el software y qué es lo que debe hacer. En teoría, el desarrollador puede consultarlo para aclarar cualquier duda que tenga sobre cómo funciona el software.
Digo en teoría, porque en la práctica esto no suele suceder. Yo mismo he tenido mi buena ración de documentos funcionales, me ha tocado escribirlos y corregirlos, pero nunca los he utilizado para lo que se supone que están hechos: para aclarar mis dudas sobre como debe funcionar un programa.
Los documentos funcionales no parecen muy útiles. Algunos expertos en hacer buen software, como la gente de 37 Signals, incluso piensan que no sirven de nada. Pero, entonces, ¿por qué seguimos haciendo documentos funcionales?
La respuesta, como casi siempre que se reincide en un error claro, no es tanto técnica como psicológica.
A muchos desarrolladores o responsables de proyectos les gustan los documentos de requisitos funcionales porque limitan su responsabilidad. Hacer buen software que contente al cliente es algo complicado; cumplir un documento de requisitos funcionales es algo mucho más sencillo. El documento funcional es una especie de contrato de lo que el desarrollador se compromete a hacer: en vez de comprometerse a hacer un software de calidad que resuelva problemas reales, el desarrollador se compromete sólo a implementar lo que está escrito en el funcional.
Si el producto no funciona bien, o no resuelve los problemas del cliente, el desarrollador se siente eximido de responsabilidad: “Mi programa cumple el funcional -dice-, si querían otra cosa, tenían que haberlo dicho en el documento funcional“. La culpa no es mía, sino del cliente, que no ha sabido escribir un buen documento funcional.
Los documentos funcionales son la excusa perfecta para hacer software chapucero y luego echarle la culpa al cliente.
Cómo distinguir a los buenos programadores
En una entrada anterior hablaba de cómo los buenos desarrolladores son altamente rentables para las empresas. Aunque sea interesante, ese es un dato TBU, -True But Useless: Cierto pero inútil. De nada nos sirve saber que los buenos programadores son muy rentables si no podemos encontrarlos. El problema, como bien señala Jorge Eduardo Olaya, es ¿cómo podemos distinguir a los buenos desarrolladores de los mediocres?
Es una pregunta complicada que no tiene una respuesta sencilla y no es extraño que muchas empresas se equivoquen con su respuesta. Los procesos que habitualmente siguen las grandes empresas para contratar gente son bastante penosos y están condenados al fracaso. Examinarlos nos puede servir, al menos, para descubrir como no se distingue a los buenos desarrolladores.
En las grandes empresas las contrataciones suelen ser responsabilidad del departamento de recursos humanos, es decir gente especializada en contratar trabajadores pero que rara vez tiene conocimientos técnicos. Y eso es lo peor que se puede hacer para encontrar buenos programadores: dejar que sólo gente sin conocimientos técnicos evalúe a los aspirantes.
Alguien sin conocimientos técnicos tiene unos medios muy limitados para saber si un aspirante es adecuado para un puesto. Al final acaba limitándose al sencillo criterio de contar las bolitas del curriculum:
- Experto en diseño de arquitecturas SOA mediante Servicios Web SOAP: 5 puntos
- Experto en diseño de arquitecturas JEE con EJBs -qué serán los EJBs piensan con razón en RRHH- 10 puntos.
- Sun Certified Enterprise Architect for the Java EE Platform: 5 puntos
- Etcétera.
¿Y qué significa eso? Alguien con la cara suficientemente dura, puede “ser experto” en cualquier cosa.
Incluso, aunque el currículum no esté inflado, es muy difícil hacerse una idea del candidato sólo con leerlo. La experiencia y los títulos son indudablemente importantes, pero dicen poco de la dedicación y la capacidad de aprender nuevas cosas que, al paso al que evoluciona la informática, son las características más importantes que debe tener un buen desarrollador.
La experiencia siempre es un grado, pero no es un criterio infalible: tampoco es raro ver a gente que lleva diez años programando sin haber aprovechado ese tiempo. Si alguien lleva diez años haciendo chapuzas, casi mejor que no tuviese esa experiencia, porque acaba tan acostumbrado a hacer chapuzas que no concibe que se pueda desarrollar software de otra manera.
Con los títulos pasa lo mismo: hay quien aprende en cada curso que hace, y hay otros muchos que sólo sacan de provecho un papel para enmarcar y dejar colgado de la pared, y una frase en el currículum.
Entonces, si todos estos métodos son tan deficientes, ¿como podemos distinguir a los buenos desarrolladores?
Para encontrar la respuesta pensemos en que, aunque alguien sin conocimientos técnicos no puede distinguir el código bien escrito del que es una chapuza, un buen desarrollador puede distinguirlos con facilidad. Hablando con un candidato puede hacerse rápidamente una idea del nivel de conocimientos del candidato, de si le interesa lo que hace y si realmente le gusta su trabajo. Si el candidato resuelve alguna tarea práctica es fácil evaluar su capacidad de enfrentarse a los problemas. Y si ha colaborado con proyectos Open Source muchísimo mejor: mirando sus contribuciones puedes hacerte una idea muy aproximada cómo trabaja ese programador.
Al final la respuesta al enigma de cómo se distingue a los buenos programadores es sencilla: los buenos programadores se distinguen entre sí.
Por qué no funciona el modelo en cascada
La ingeniería del software es una recién nacida: la humanidad lleva miles de años construyendo edificios, barcos y puentes, pero sólo unas décadas construyendo software.
Cuando nació la ingeniería del software se fijó en sus hermanas para descubrir como se hace eso de construir sistemas complejos. Y, básicamente, la ingeniería del software copió los métodos tradicionales en lo que se conoce como Modelo en Cascada.
En el Modelo en Cascada, los ingenieros hacen primero un análisis de los requisitos del proyecto: Si se va a construir un puente, hay que saber qué capacidad de tráfico tiene que atravesar el puente, los vientos, mareas y temblores que debe soportar, etc. Con todos estos requisitos se hace un documento funcional explicando cómo debe funcionar el puente cuando esté acabado. Al documento funcional le sigue un diseño técnico: en una obra serían los planos que modelarían el puente, las instrucciones para construir el puente. Una vez se tiene un plan, hay que construir el puente. Cuando el puente está construido, pasamos a la fase de mantenimiento. Este es, muy resumido, el modelo en cascada.
Este sistema funciona razonablemente bien en las ingenierías tradicionales, pero fracasa estrepitosamente en la ingeniería del software. ¿Por qué? Porque los requisitos y el proceso de construcción del software son de naturaleza completamente distinta al los de la construcción de un puente.
Cuando se construye un puente, todos los requisitos y las funciones que debe cumplir deben estar especificados de antemano. Hay que hacer un plano que detalle al milímetro cómo va a ser el puente y seguirlo al pie de la letra. Una vez se empieza a construir un puente, no podemos cambiar de opinión a la mitad y decir, “no nos habíamos dado cuenta, pero necesitamos que los barcos puedan navegar por debajo del puente. Cámbiame el puente que estas haciendo por un puente levadizo“. Por desgracia, una vez hemos puesto los cimientos, el diseño no se puede alterar demasiado.
En cambio, en el desarrollo de software los requisitos cambian constantemente. Y eso no es algo malo, sino que es una ventaja que deben aprovechar los buenos desarrolladores.
En vez de planificar todo de antemano, y seguir el plan al pie de la letra, es bueno permitir cierta flexibilidad para que el proyecto vaya creciendo orgánicamente y se vaya definiendo con el tiempo. Puede que el cliente se dé cuenta de que lo que ha pedido no es exactamente lo que necesita, sino que, en realidad, quiere un producto ligeramente diferente. O muy diferente. Eso está bien: nos hemos dado cuenta y podemos corregirlo antes de que el cliente se quede con un producto que no resuelve sus problemas. Cambiar el diseño a mitad de proyecto hace que el producto final sea más eficiente y, sobre todo, satisfaga mejor las necesidades del cliente.
Muchos proyectos tremendamente exitosos empezaron siendo siendo una cosa y terminaron siendo otra completamente distinta, pero fue precisamente este cambio el que les permitió triunfar. Flickr, por ejemplo, empezó como un juego online, pero los desarrolladores se dieron cuenta de que una inocente funcionalidad que permitía a los jugadores compartir fotos se estaba convirtiendo en la estrella de su servicio. Fueron inteligentes y cambiaron sus requisitos iniciales; acabaron convirtiendo un juego medianamente exitoso, en un servicio para compartir fotos tremendamente exitoso.
Flickr no es un caso único. Blogger nació como un servicio de gestión de proyectos; en sus comienzos, Paypal era una plataforma para hacer micropagos con las Palm Pilot… Puede decirse que la mayoría de los proyectos exitosos no lo son por sus ideas originales, sino por la facilidad que tienen de adaptarse a los cambios y a las nuevas oportunidades.
Pero -estaréis pensando- ¡cambiar los requisitos a mitad de un proyecto tiene un coste muy grande! Eso no se puede hacer. ¿No?
Sí y no. Cambiar los requisitos tiene un coste muy grande cuando se sigue el modelo en cascada, en el que toda la planificación se hace de antemano, y cada fase depende muchísimo de que la anterior se haya hecho bien. En esas circunstancias, cambiar la planificación significa echar por tierra mucho esfuerzo y trabajo.
Pero el modelo en cascada no es la única manera de hacer software.
(Las cascadas son bonitas, pero no para hacer software)
En los últimos diez años han surgido una variedad de metodologías ágiles que apuestan por desarrollar software de forma iterativa: se van añadiendo funcionalidades en iteraciones pequeñas, de unas pocas semanas. Tras cada iteración se evalúan los requisitos para ver si siguen siendo las necesidades reales del cliente, y en consecuencia se planea la próxima iteración. Es natural posponer los problemas hasta que tengamos más datos, y si necesitamos cambiar la planificación, tampoco perdemos tanto trabajo porque, en realidad, tampoco hemos invertido tanto esfuerzo planificando.
En el desarrollo ágil los cambios de requisitos no se ven como un inconveniente, sino como una ventaja potencial. Como dice el Manifiesto Ágil:
Valoramos más la respuesta ante el cambio que el seguir un plan.
…
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Los buenos programadores son un chollo
Existe un trabajo seminal en la ingeniería del software: The Mythical Man Month. En este libro de 1975 Fred Brooks ya citaba algunos estudios en los que se mostraba que los mejores programadores pueden ser hasta diez veces más productivos que un programador medio.
Los encargados de un equipo de programación han reconocido desde hace tiempo una gran diferencia entre la productividad de los buenos programadores y los malos. Pero cuando vimos estas magnitudes medidas, todos nos quedamos asombrados. En uno de sus estudios, Sackman, Erikson, y Grant midieron el rendimiento de un grupo de programadores experimentados. Dentro de este grupo, los ratios entre los mejores y los peores eran de media 10:1 en las medidas de productividad y de un increíble 5:1 para las medidas de rendimiento del programa. (…) Los datos también mostraron que no existe ninguna relación entre la experiencia y el rendimiento, aunque dudo que esto sea siempre cierto.
Frederick P. Brooks, The Mythical Man-Month
Este hecho es muy importante para las empresas que necesitan programadores ya que un programador, por muy productivo que sea, nunca cobra diez veces más que un compañero. Imaginemos, por ejemplo, que un programador normalito puede cobrar unos 25.000 euros al año, mientras que su compañero, un programador fuera de serie, puede cobrar el doble: 50.000 euros al años. Si el programador fuera de serie puede hacer el trabajo de 10 programadores normalitos, eso quiere decir que contratándolo la empresa gasta más en un sueldo, pero se ahorra otros nueves sueldos. En nuestro ejemplo, el ahorro sería de 200.000 euros al año, o cuatro veces más que el sueldo del programador fuera de serie.
En resumen: los buenos programadores pueden parecer caros pero si hacemos las cuentas, en realidad son un chollo.
