¡La estimación es alquimia! No podemos calcular el número de documentos y funcionalidades y simplemente multiplicarlos por algún factor que nos dé una respuesta mágica.

Y no podría estar más de acuerdo. Hay demasiadas variables en juego como para poder hacer una estimación más o menos precisa. Interoperabilidad, accesibilidad, SEO, diseño gráfico, diseño de interfaces, programación en el servidor, programación de interfaces, optimización del código, calidad, seguridad, documentación, gestión del proyecto, etc. Además, distintas personas/equipos pueden trabajar puntualmente juntos en determinadas secciones, como el diseñador gráfico junto con expertos en márketing y usabilidad.

Si bien es cierto que en páginas corporativas sencillas todo el trabajo puede condensarse en pocas horas y es fácil calcular el plazo de entrega, cuando el desarrollo es complejo y requiere de un equipo de personas trabajando en paralelo, el número de horas puede dispararse de forma dramática, arruinando un proyecto, incumpliendo plazos y perdiendo clientes.

¿Entonces cómo se suelen estimar los proyectos? Existen numerosos métodos. Sin embargo, la mayoría de ellos se basan en fórmulas que utilizan como premisa prever el número de líneas de código que tendrá el proyecto, lo cual en mi opinión nos puede llevar a una situación incluso peor. No es lo mismo una línea de código en Perl que en un framework como Ruby on Rails, ni todos los programadores codifican igual. Además, hay muchos factores implicados en la creación de software aparte de la programación.

En mi opinión lo que mejor funciona es conocer de forma precisa todos los hitos semanales del proyecto, y basándonos en un histórico, podremos hacer una estimación bastante más precisa. Pero surge el gran problema: Necesitaríamos un análisis detallado de la aplicación, y cuando hacemos presupuestos tenemos que ser ágiles, no debemos hacer esperar al cliente.

Para explicar el problema utilizaré la clásica analogía de la construcción de edificios. Supongamos que un cliente desea una vivienda, acude al equipo de albañiles y les dice “Quiero algo muy sencillo. Una vivienda con 3 dormitorios, salón y cocina. ¿Por cuánto me saldría?”. Lógicamente le exigirán muchos más detalles. ¿Sobre qué tipo de suelo se trabaja? ¿Qué tipo de construcción quiere? ¿Cuál será la disposición final de las habitaciones? ¿Cuántos baños tendrá? ¿Dónde irán estarán los interruptores? ¿Hace falta conexión telefónica en los dormitorios? ¿Querrán garaje? En definitiva, es necesario que un arquitecto haya definido previamente y de forma precisa todos los detalles de la vivienda.

En el desarrollo web esto prácticamente nunca sucede. Bajo unas sencillas premisas se presupuesta algo tan versatil como una página. Pongamos un ejemplo sencillo: El cliente quiere añadir a su actual página un módulo para añadir noticias que se puedan comentar. Para ello desea que los usuarios se autentiquen. Existen muchas formas de realizar esto. Podríamos crear un usuario maestro que se autenticara mediante HTTP. Otra opción sería tener varios usuarios preestablecidos creados en una base de datos o en un fichero, que ingresaran mediante un formulario HTML y se usara una cookie para manejar sesiones. O bien podría tambien permitirse que cualquier persona se registrara para así poder firmar comentarios con su usuario, y que desde un panel de control el administrador pueda actualizar sus permisos para permitirles poder publicar noticias. Además, se podría añadir confirmación por correo electrónico, códigos de seguridad captcha tras un determinado número de intentos de acceso fallidos, recuperación de contraseña, o numerosos campos que poder rellenar, como localidad, usuario de mensajería instantánea, fecha de último acceso o firma en sus comentarios.

Partiendo de una premisa sencilla hemos llegado a soluciones muy distintas. Es posible definir brevemente estos detalles en el presupuesto, pero en proyectos medianos/grandes nunca llegará a ser suficientemente preciso como para asegurarnos un error en la estimación asumible. Necesitaríamos de un riguroso análisis y diseño previo, para posteriormente realizará la codificación, pruebas e implantación.

De este modo, la creación de proyectos software disfrutarían de una notable mejora en la gestión si se dividiera al menos en dos etapas:

1. Análisis y diseño
2. Codificación, pruebas e implantación.

No sólo sería sano para el sector de desarrollo, sino que nos obligaríamos a seguir un orden, unas pautas de trabajo, que repercutirían notablemente en la calidad del producto, con lo que el cliente estaría mucho más satisfecho.

Cuando una persona quiere construir una vivienda, proporciona a los constructores los planos y detalles de ésta. Cuando el Estado saca a concurso la construcción de un nuevo tramo de autovía, facilita toda la información necesaria de su recorrido y de la calzada de forma precisa. La ingeniería del software es una disciplina aun adolescente. Quizás deba aprender de sus mayores.

Situación 1

Carretera convencional. El coche negro, en vista de que en sentido contrario no viene nadie, decide adelantar. Mientras, el coche amarillo decide salir hacia su izquierda, pues le da tiempo a incorporarse, por su derecha no viene nadie y no ha visto al coche negro adelantando. Se chocan ¿Quién tiene la culpa? ¿Cómo se debería evitar?

Situación 2

Carretera convencional. El coche negro decide adelantar. Justo cuando empieza, el coche amarillo comienza a torcer para incorporarse al camino a su izquierda. Todos los vehículos se ven obligados a reducir drásticamente la velocidad, incluido el negro. Al salir de la calzada el amarillo, el negro descubre al vehículo azul justo frente a él y chocan. ¿Quién tiene la culpa? ¿Cómo se debería evitar?

Situación 3

Carretera convencional. Un ciclista circula por el arcén cuando cruza un carril deceleración. A su izquierda, un vehículo quiere salir de la calzada. ¿Quién debe ceder el paso a quién?

Situación 4

Autovía de 3 carriles. El coche negro acaba de adelantar al rojo y, en vista de que no ve ningún vehículo más, decide incorporarse al carril central. A la vez, el coche amarillo decide adelantar al verde. El negro y el amarillo chocan. ¿Quién tiene la culpa? ¿Cómo se debería evitar?

Si alguien está seguro de conocer la respuesta, mis amigos y yo os lo agradecermos

En el mundo web es igualmente interesante poder empotrar imágenes dinámicas generadas mediante SVG. Por ejemplo, hace un tiempo quise hacer unos mapas de densidades de población por municipios generados de forma automática para la Wikipedia. En realidad es muy sencillo. En ese caso podemos partir de una imagen con un objeto por cada término municipal, y mediante un editor de SVG (Por ejemplo, Inkscape) editar las propiedades del objeto y establecer como ID el código postal del municipio. De ese modo, podremos acceder mediante DOM al objeto que representa cada término municipal para posteriormente establecer el color de fondo dependiendo de su densidad (Expresiones regulares al rescate).

Y es que a veces nos complicamos mucho la vida, como por ejemplo dibujando a pelo polígonos sobre la API de Google Maps, cuando incluso podemos empotrar directamente imágenes SVG en un mapa de Google.

A día de hoy, la mayoría de los navegadores permiten visualizar directamente imágenes vectoriales SVG dentro de un documento XHTML, pero como a menudo sucede, Internet Explorer no renderiza de forma nativa SVG. ¿Qué podemos hacer en esos casos? Muy sencillo. Convertir dinámicamente a un mapa de bits. En el caso de PHP no he encontrado ninguna biblioteca o clase que permita la conversión de forma eficaz, sin embargo existen utilidades en la línea de comandos a las que podemos llamar para que realicen conviertan al formato deseado (Como el propio Inkscape o la utilidad convert de ImageMagick).

Los comienzos

Muchos hemos hecho nuestras primeras páginas web con aplicaciones para editar HTML. Es ahí cuando empiezas a descubrir lo útiles que son todos los controles de usuario como botones, cajas de texto, tablas, etiquetas o menús. Suele ser una lección precipitada de Interfáces Gráficas de Usuario. Sin embargo pronto necesitas tener más control sobre tu página, por lo que decides indagar en HTML y descubres las maravillas de los Lenguajes de Marcado, una forma muy sencilla de intercambiar información entre máquinas. A la vez, compruebas que no es una buena idea repetir tantas definiciones sobre cómo mostrar la web en cada uno de los ficheros, por lo que aprendes CSS, y lo que es más importante, comprendes la necesidad de separar en capas la información en sí, y el cómo se muestra. Pero no todo funciona como esperabas, ya que tu web no se comporta igual en todos los navegadores, y ahí es cuando descubres lo importante que es que exista un organismo regulador que establezca los estándares, el W3C.

Pero ahora no sólo quieres que tu página esté bien estructurada y que sea compatible con todos los navegadores, sino que además quieres que luzca bonita (Diseño Gráfico), que sea intuitiva (Usabilidad) y accesible a cualquier usuario (Accesibilidad).

Pasos intermedios

Pronto tu página empieza a crecer, y necesitas ahorrarte trabajo a ti y al usuario. Es cuando de verdad entra en juego la programación. Pero resulta que hay dos lugares en los que programar, en el servidor y en el cliente (Aprendes sobre la estructura cliente-servidor). En el lado del cliente utilizas JavaScript, que es un lenguaje de programación estructurado, y en el lado del servidor PHP, ASP, JSP, Ruby, Python o cualquier otro, la mayoría de ellos lenguajes orientados a objetos.

Y pronto surge la necesidad de almacenar información de una forma robusta, sencilla y escalable, y es cuando aprendes a Diseñar Bases de Datos y a generar consultas mediante SQL. ¡Ahora tus páginas sí empiezan a ser de verdad escalables! Independientemente de si eres el administrador o no del servidor de bases de datos, has aprendido numerosas nociones de qué es un Sistema Gestor de Bases de Datos Relacionales. Ahora estás utilizando una estructura de 3 capas: Cliente – Servidor de aplicaciones – Servidor BBDD.

Pronto necesitarás gestionar las sesiones de usuario, por lo que casi con total seguridad deberás aprender sobre las cookies, y querrás poder gestionar redirecciones, si tus páginas se deben almacenar en una memoria caché o mostrar errores de página no encontrada. En consecuencia, debes aprender sobre HTTP, que no es más que un Protocolo de Nivel de Aplicación. Además has aprendido cómo dotar de estado a un protocolo que no almacena estado.

Con el tiempo la lógica de las aplicaciones web que desarrollas empieza a ser más compleja, pero siempre hay patrones que se repiten, por lo que decides aprender más acerca de Patrones de Diseño, e incluso utilizas algún Framework de desarrollo. Puede que incluso decidas conocer alguna metodología de desarrollo como Programación eXtrema.

La cosa se complica

Un día tu página empieza a tener mucho tráfico, y tu alojamiento compartido se te queda pequeño. Entonces decides utilizar un servidor dedicado. Ahora no sólo tienes que gestionar tu página, sino que debes preocuparte por la seguridad de la red con un firewall y una buena política de permisos. Gestionarás el servidor de bases de datos, de correo electrónico, de páginas web, de ficheros, etc. Es decir, aprendes a gestionar servicios críticos, por lo que ya tienes nociones de administración de sistemas.

Además quieres poder interactuar con otras páginas, bien sea integrando su información, o facilitando la que tiene la tuya. En el segundo caso necesitas generar una API para que los demás puedan acceder a tu información, y a ser posible exportando en lenguaje como XML o JSON.

Luego deseas optimizar tu página para que sea más veloz, y entonces empiezas a utilizar servidores de caché.

Aquí ya hablo desde la inexperiencia total, pero imagino que llega un momento en que tu página debe estar alojada en un cluster (Computación Distribuída) para poder delegar todo el tráfico a distintos servidores y obtener tolerancia a fallos.

Resumiendo

En el desarrollo web tienes la posibilidad de aprender y conjugar:

• Interfáces Gráficas de Usuario
• Lenguajes de Marcado
• Separar en capas
• Estándares Web
• Diseño Gráfico
• Usabilidad
• Accesibilidad
• Estructura cliente-servidor
• Lenguajes de Programación Estructurados
• Lenguajes orientados a objetos
• Diseño de Bases de Datos
• SQL
• Sistema Gestor de Bases de Datos Relacionales
• Protocolos de Nivel de Aplicación
• Aplicaciones web
• Patrones de Diseño
• Frameworks de desarrollo
• Seguridad de la red
• Administración de sistemas
• APIs
• XML o JSON
• servidores de caché
• Computación Distribuída
• Tolerancia a fallos
• Y un largo etcétera

¿Y quién dijo que hacer páginas web era una cosa sencilla?

ADSL convencional

• Precio – 40,90€/mes
• Ancho de banda de descarga – 3Mbps
• Precio por Mbps – 40,90 / 3 = 13,63€

Trailer

Un disco duro cualquiera:

• Capacidad – 750GB
• Peso – 0,63Kg

Un trailer cualquiera:

• MMA – 24.000Kg
• Precio kilómetro – 3,35€

Por tanto un trailer puede transportar 38095 discos duros, o lo que es lo mismo, alrededor de 27.000GB

Supongamos un viaje de 600Km. A una media de 80Km/h, al trailer le llevaría 7,5 horas. Luego el ancho de banda del camión es: 27.000 / 7,5*60*60 = 1GBps. ¡Pero espera! Estamos hablando de bytes, no de bits. Para compararlo con nuestra conexión ADSL tendremos que multiplicar por 8, con lo que el ancho de banda del camión queda en 8Gbps. No está nada mal, ¿verdad?

Aun queda lo mejor. ¿A cuánto sale el Mbps si utilizamos un trailer?

• Precio del trayecto – 600 * 3,35 = 2010€.
• Precio del Mbps – 2010 / 8000 = 0,25€

Así pues, nunca subestimes el ancho de banda del camión.

Relacionado: El precio de los mensajes de texto es muy superior a transmitir datos desde el Hubble.

No es la primera vez que lo intento. En realidad es la tercera. La primera ocasión fue en mi servidor de casa, pero los 128kbs de subida que había por entonces no eran suficiente para permitir una buena conexión. ¿Acaso lo es la tercemundista conexión que disfrutamos hoy en este país los abonados a ADSL? El segundo intento fue en un servidor compartido al que apenas dí uso, por lo que finalmente, decidí no renovar el dominio (Era chuso.net, por si alguien quiere regalarme algo y no sabe el qué). He pasado de lo más personal (servidor casero), a una solución semi personal (servidor compartido) a finalmente dejarlo totalmente en manos de terceros.

¿Y por qué hoy? Llevo un tiempo con ganas de experimentar en primera persona el fenómeno blog, y el microblogging no me acaba de llamar la atención. En realidad creo que me gusta ir un paso por detrás. Nunca me llamó la atención tener equipos de última generación, al igual que ahora no siento ningún tipo de pasión por twitter o las tan de moda redes sociales. Quizás esa es una razón por la que siendo 2008 decido empezar de nuevo un blog. Pero desde luego hay más.

Ayer asistí al iniciador de junio, donde pude disfrutar de la experiencia de Rodolfo Carpintier sobre modelos de negocio en Internet. Antes de continuar es importante que resalte lo esclarecedora que fue su presentación. Muchas de las ideas difusas que yo tenía hechas me las confirmó. Por contra también recibí algunos jarros de agua fría (De eso hablaré otro día). Soy una persona introvertida, pero tras la presentación tuve la oportunidad de conocer a gente muy interesante, la mayoría de ellos bloggers. Ese fue el empujón que me faltaba para lanzarme de nuevo a este mundo. ¡Espero volver!

Y aquí estoy, llego tarde, pero ojalá tenga constancia y las ganas vayan en aumento. Nos vemos

Actualizacion 19 de octubre de 2009: Desde hoy, también están alojados los artículos de otros blogs que tuve.