"Este sitio web es bastante simple, todo lo que necesitas hacer es completar X, Y, Z. Pareces tener mucho talento técnico, así que creo que no necesitarás demasiado tiempo para montarlo."
De vez en cuando recibo correos electrónicos así. Quienes los escriben casi siempre son personas ajenas a la tecnología, o que están trabajando en su primer producto. Al principio, me molestaba mucho cuando la gente decía eso. ¿Con quién están discutiendo sobre el tiempo que requiere el desarrollo de software? Pero luego me di cuenta de que ni siquiera yo puedo predecir cuánto tiempo llevarán mis propios proyectos. Si yo mismo no lo hago bien, ¿por qué habría de enfadarme con esas personas?
Lo que realmente me frustra no es que sus estimaciones sean erróneas. El problema es que creen que pueden hacer una estimación correcta. Como desarrolladores, a menudo descubrimos que, en los problemas de desarrollo de software, un profano tiende naturalmente a subestimar cosas complejas.
Esto no es una excusa para nuestro enfado. Pero plantea otra pregunta interesante: ¿por qué nuestra capacidad innata para predecir la complejidad falla cuando nos enfrentamos a problemas de programación?
Para responder a esta pregunta, veamos cómo nuestro cerebro estima las cosas. Algunas cosas son fáciles de estimar correctamente incluso para personas sin experiencia, pero otras no.
Pensemos en ver a alguien tocar la guitarra. Incluso si nunca has tocado la guitarra, después de ver una interpretación de «Mary Had a Little Lamb», puedes deducir aproximadamente que es simple y que no se necesita mucha habilidad para tocarla. Del mismo modo, después de ver a alguien tocar el Canon de Pachelbel en re mayor (Pachabel's Canon), también es fácil deducir que es complejo y que requiere mucha práctica para interpretarlo.
¿Por qué podemos estimar de forma rápida y precisa la complejidad de estas dos piezas? Tiene que ver con nuestro método para juzgar si algo es simple o complejo. Nuestro cerebro tiene algunos patrones ya preparados para hacerlo; el primero se basa en la velocidad. En este caso, el cerebro distingue cuántas cosas se tocan por segundo. Según cuántas cosas se tocan por segundo, es fácil tener una intuición de la complejidad de la pieza. Como tocar una canción con la guitarra es un proceso físico, una actividad sensorial, a nuestro cerebro le resulta fácil inferir la velocidad y luego convertirla en complejidad.
Tenemos otra base innata de inferencia: el volumen. Piensa en comparar una tienda de campaña con un edificio de apartamentos. Incluso si alguien nunca ha estudiado arquitectura, puede decirte que normalmente diseñar y construir una tienda es más simple que diseñar y construir un edificio de apartamentos. ¿Por qué? Porque naturalmente usamos el volumen físico como indicador de la complejidad de las cosas.
Por supuesto, estos dos análisis lógicos no siempre son 100% efectivos. Pero en la mayoría de los casos, la gente hace esto y le funciona. En la mayoría de las situaciones, al evaluar procesos físicos, nuestro cerebro establece una correlación efectiva con los objetos físicos, sin necesidad de experiencia previa.
Ahora hablemos del software. Cuando una persona que no sabe de tecnología intenta estimar el tiempo de desarrollo de software, hay dos indicadores intuitivos muy básicos que la ayudan: la complejidad medida por el volumen y la complejidad medida por la velocidad. Pero no se dan cuenta de que el software no es como se imaginan. El software, en esencia, no es materia tangible. No tiene volumen ni velocidad. Sus diminutas partes pueden destellar en la pantalla de vez en cuando. Por eso, al enfrentarnos al desarrollo de una aplicación web (o de cualquier tipo de software), nuestra intuición básica falla.
El primer punto, la velocidad, obviamente no puede ser usado por un profano para evaluar software. Así que naturalmente tienden a usar el indicador de volumen: o por el número de páginas del documento de descripción, o por el número de casos de uso o características del software.
A veces, este método de estimación sí funciona. Ante un sitio web estático, sin requisitos de diseño especiales, un profano puede estimar fácilmente el tiempo de desarrollo con este método. Pero, por lo general, en el desarrollo de software, el volumen no refleja eficazmente la complejidad.
Desafortunadamente, la única forma efectiva de inferir la complejidad del software es mediante la experiencia. Y ni siquiera siempre funciona. Como programador, sé que, según las funciones similares que he desarrollado antes, puedo estimar cuánto tiempo tomará cada una de las funciones actuales. Luego sumo el tiempo total y obtengo una estimación aproximada del tiempo necesario para completar todo el proyecto. Sin embargo, en la práctica, cada proyecto se encuentra con dos o tres cuellos de botella durante el desarrollo. Estos cuellos de botella pueden consumir una gran cantidad de tiempo del programador sin que puedas preverlos antes de encontrártelos. Retrasan todo el proyecto y posponen la finalización durante semanas o incluso meses.
Esto es algo que las personas sin experiencia no entienden al evaluar la complejidad. No comprenden por qué un método que funciona bien en otras cosas no funciona en el desarrollo de software. Así que la próxima vez que oigas a alguien decir: "Creo que puedes desarrollarlo en unos pocos días", venga de quien venga, no te molestes. Respira hondo, pásale la dirección de este artículo y sigue haciendo lo que tenías que hacer.
Texto original en inglés:I'm Sure It Will Only Take You A Few Days To Code ]