Joel on Software

Joel on Software   La Opinión de Joel sobre qué es Software

 

Otros artículos de "Joel on Software" en Español

Otros artículos de "Joel on Software" en Inglés

Envíele un Email al autor (solo en Inglés)

 

Nada es tan simple como parece


Por Joel Spolsky
Traducido por Gerardo Barroeta
Editado por Jerry Elizondo
4 de Marzo de 2002

Tuvimos un pequeño problema de usabilidad en CityDesk.

Este fue el problema: se podían importar archivos desde web usando un comando de menú (“Import Web Page”). Y se podían importar archivos desde disco hacia CityDesk arrastrándolos con el mouse. Pero no había comando de menú para importar archivos desde un disco. Así es que o la gente no descubrió que era posible, o la gente intentó usar la característica de Importar Página Web para importar desde un disco, lo cual no funcionaba correctamente.

Pensé que seria fácil de arreglar con un asistente de dos páginas. A grandes rasgos, la primera página te preguntaría “Desde donde quieres importar?” Si escogías “disco”, la página dos te pediría un archivo. Si escogías “web”, la página dos te pediría un URL.

Estuve a punto de comenzar a implementar esto, pero algo me detuvo, y en cambio, comencé a escribir una mini-especificación. Aquí esta la especificación, en su totalidad:

Página Uno
¿Desde donde quieres importar? (Disco/Web)

Página Dos (Disco)
¿Diálogo estándar de Archivo/Abrir?

Página Dos (Web)
¿Campo de URL con mini-navegador-web?

De pronto algo se me ocurrió. ¿Se puede poner el diálogo estándar de Windows de abrir archivo, el cual es usualmente provisto de facto por el SO, en un Asistente?

Hmm.

Investigue. Sí, se puede, pero no es divertido y lleva algunas horas de trabajo. ¿Cómo podría hacer que ésto no fuera un Asistente? Reescribí la especificación:

Dos Artículos de Menú:
1) Importar Página Web Desde Internet
-> Muestra Diálogo URL
2) Importar Página Web Desde Disco -> Muestra Dialogo de Abrir Archivo

Mucho mejor. Tres minutos de diseño me ahorraron horas de codificar

Si has pasado mas de 20 minutos de tu vida escribiendo código, probablemente ya habrás descubierto una buena regla general: nada es tan simple como parece.

Algo tan sencillo como copiar un archivo está lleno de peligros. ¿Qué pasa si el primer argumento es un directorio? ¿Qué pasa si el segundo argumento es un archivo? ¿Qué pasa si un archivo con el mismo nombre ya existe en el destino? ¿Qué pasa si no tienes permisos de escritura?

¿Qué pasa si la copia falla a la mitad? ¿Qué pasa si el destino se encuentra en una máquina remota que está disponible, pero la cual requiere autenticación para continuar? ¿Qué pasa si los archivos son largos y la conexión es lenta y necesitas mostrar un indicador de progreso? ¿Qué pasa si la velocidad de transferencia disminuye a casi cero... ¿cuándo te das por vencido y regresas un mensaje de error?

Una buena forma de entrevistar candidatos para trabajos en pruebas es darles una operación simple y pedirles que enumeren todas las cosas que podrían salir mal. Una pregunta clásica de Microsoft en entrevistas de pruebas: ¿cómo pruebas el cuadro de diálogo de Abrir Archivo? Un buen probador será capaz de sacudirse varias docenas de cosas extrañas a probar (“archivo es eliminado por otro usuario entre el tiempo que esta listado en el cuadro y el tiempo en el que lo seleccionas y presionas Abrir”).

OK, entonces tenemos un axioma: nada es tan simple como parece.

Hay otro axioma en la ingeniería de software, que es siempre tratar de reducir el riesgo. Una pieza particularmente importante de riesgo a evitar es el riesgo con la agenda, cuando algo toma más tiempo de lo esperado. El riesgo con la agenda es malo porque tu jefe te grita, lo cual te hace infeliz. Si esa no es motivación suficiente para ti, la razón económica por la que el riesgo de agenda es malo es porque decidiste hacer una característica basada en información de que tomaría 1 semana. Ahora que te das cuenta de que ha tomado 20 semanas para completar, esa decisión bien podría haber estado mal. Tal vez si hubieras sabido que iba a tomar 20 semanas, habrías tomado una decisión diferente. Mientras más decisiones malas hagas, más probable será que todas esas maletas con el logo de tu compañía terminen en el almacén del liquidador mientras tu ex-CEO lloriquea que “lo que apesta es, que ni siquiera fuimos lo suficientemente exitosos para ser mencionados en fuckedcompany cuando cerramos!”

La combinación de nada-es-tan-simple-como-parece y reducir-riesgo solamente pueden llevarte a una conclusión:

Debes diseñar las cosas antes de que las implementes

Siento decepcionarte. Sí, lo se, leíste a Kent Beck y ahora crees que esta bien no diseñar las cosas antes de que las implementes. Lo siento, no esta bien. Tu no puedes cambiar las cosas en código “tan fácilmente” como las podrías cambiar en los documentos de diseño. La gente dice esto todo el tiempo y están equivocados. “Usamos herramientas de alto nivel en estos días, como Java y XML. Podemos cambiar las cosas en minutos en el código. ¿Porque no diseñar en código?” Amigo mío, le puedes poner llantas a tu mamá pero eso no la convierte en autobús, y si crees que puedes refactorizar tu función mal implementada de copiar archivo para hacerla preferente (preemptive) en vez de hilada (threaded) tan rápido como Yo puedo escribir ese enunciado, te encuentras en negación profunda.

De cualquier forma, No creo que Programación Extrema realmente abogue cero diseño. Ellos solamente dicen “no hagas más diseño del que se necesita”, lo cual está muy bien. Pero eso no es lo que la gente oye. La mayoría de los programadores están buscando cualquier excusa que puedan encontrar para no hacer diseño básico antes de implementar características. Entonces se apegan a la idea de “no diseño” como moscas en un mata-insectos. Dzzzzzzt! Es una de esas raras formas de pereza en las que terminas haciendo más trabajo del que hubieras hecho de otra forma. Soy demasiado perezoso para diseñar la característica primero en papel, así es que escribo algo de código, y entonces no está bien, así es que lo tengo que arreglar, y gasto más tiempo del que hubiera gastado de la otra manera. O, mas comúnmente, escribo algo de código, y entonces no está bien, y mi producto es inferior y me paso hasta el final del tiempo inventando excusas de porque “tenia que ser de esa forma”. Es torpe y nada profesional.

Cuando Linus Torvalds critica el diseño se refiere a sistemas inmensos, los cuales tienen que evolucionar, o se convierten en Multics. No se refiere acerca de tu código de Copiar Archivo. Y cuando consideras que él tenía un mapa bastante claro de hacia donde iba, no es de extrañarse el porque Linus no ve mucho valor en el diseño. No caigas por eso. Lo más probable es que no se aplique a ti. Y de cualquier manera, Linus es mucho más inteligente de lo que nosotros somos, y las cosas que funcionan para él no funcionan para nosotros la gente común.

El diseño e implementación incremental es buena. Lanzamientos frecuentes están bien (aunque para software empaquetado o de mercados masivos, vuelve locos a los clientes, nunca una buena idea – en su lugar haz actualizaciones internas). Demasiada formalidad en el diseño es una perdida de tiempo – Nunca he visto que un proyecto se beneficie de diagramas de flujo sin sentido o “UMLing” o “CRCing” o lo que sea el sabor del día. Y esos sistemas inmensamente monstruosos de 10 millones de líneas de código a los que Linus se refiere deberían evolucionar porque los humanos no saben realmente diseñar software en esa escala.

Pero cuando te sientas a escribir Copiar Archivo, o cuando te sientas a planear las características del siguiente lanzamiento de tu software, tienes que diseñar. No dejes que las sirenas te persuadan de lo contrario.



Esté articulo apareció originalmente en Inglés con el nombre Nothing is as Simple as it Seems  

Joel Spolsky es el fundador de Fog Creek Software, una pequeña empresa de software en Nueva York. Es titulado por la Universidad de Yale y ha trabajado como programador y gerente en Microsoft, Viacom, y Juno.


El contenido de estas páginas representan la opinión de una persona.
Todo el contenido es Copyright ©1999-2005  por Joel Spolsky. Todos los derechos son reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky