140

Este artículo es una traducción libre del post There are no small changes de Des Traynor.

“Queremos limitar a 140 la cantidad de caracteres que permitimos para los comentarios en nuestra aplicación, ya que el día de mañana nos gustaría poder enviarlos por SMS. Eso es un cambio pequeño y rápido ¿no?”

Definitivamente no.

No hay pequeños cambios cuando te comprometes a producir software de calidad. Analicemos el caso presentado. Un programador web novato podría realizar el cambio mencionado en unos pocos minutos. Sin embargo, hay que considerar varios aspectos.

¿Qué pasa cuando el comentario supera los 140 caracteres? ¿Lo recortamos o simplemente mostramos un mensaje de error? Si aparece un error ¿Dónde lo mostramos? ¿Qué dice el mensaje de error? ¿Quién es el responsable de redactarlo? ¿Cómo explicamos al usuario el motivo por el cual lo estamos limitando a 140 caracteres? ¿Cómo se verá este mensaje de error? ¿Tiene un estilo definido? ¿Quién será el responsable de diseñarlo?

Suponiendo que recibamos respuestas concretas a todas las preguntas anteriores, todavía no hemos terminado. Llevar la información hasta el servidor sólo para realizar una comparación del largo de una cadena no es lo ideal, ya que la validación la podemos realizar del lado del cliente con javascript. Lo que nos lleva a nuevas preguntas.

¿Quién escribirá el código javascript? ¿En cuáles navegadores deberíamos comprobar su funcionamiento? ¿Utilizaremos un framework javascript? ¿Esta validación nos muestra el mismo mensaje de error que la validación del servidor? ¿La aplicación necesita funcionar también si javascript está desactivado en el cliente?

Ahora pongámonos en lugar de los usuarios. Ya se sentirán frustrados por el hecho de que se les impone una limitación de 140 caracteres por un motivo que no comprenden y además tienen que estar adivinando cuántos caracteres llevan escritos en el mensaje. Tiene que haber una mejor manera, al menos incorporemos un contador de caracteres… Pero…

¿Dónde estará ubicado dicho contador? ¿Quién se ocupará de diseñarlo para que se vea correctamente? Cuando el usuario llegue al límite de caracteres permitidos ¿Le prohibiremos que siga escribiendo? ¿Qué sucede si copia y pega un texto muy largo?

Suponiendo que todos estos problemas fueron resueltos, se codificó y programó todo correctamente, se hizo el testing adecuado, se comprobó el funcionamiento en todos los navegadores, se diseñó teniendo en cuenta que sea usable y accesible, se implementó en el servidor de producción y ya está funcionando. Ahora llega el feedback del usuario.

¿Cómo le explicamos a un usuario que ayer otras personas pudieron escribir comentarios más largos y ahora le estamos imponiendo límites? ¿Quién se ocupará de responderles y explicarles estas limitaciones? ¿Hemos realizado una evaluación de los riesgos de perder usuarios?

Y todo esto por una simple limitación en la cantidad de caracteres de un mensaje, no imaginemos lo que sucedería si tenemos que realizar cambios más complejos.

Conclusión: incorporar cambios o nuevas funcionalidades en una aplicación que ya está funcionando, nunca es fácil, pero tampoco imposible. Ningún cambio es pequeño cuando se quiere desarrollar software de calidad.