Mostrando entradas con la etiqueta arquitectura. Mostrar todas las entradas
Mostrando entradas con la etiqueta arquitectura. Mostrar todas las entradas

lunes, 10 de febrero de 2014

365 - El principio de Peter

(no quiero iniciar un flame Arquitectura VS. desarrollo; solo uno de "Mala arquitectura" VS "desarrollo y luego ya pienso cómo lo distribuyo todo". O mejor, lanzar una pregunta: "¿por qué tengo que elegir entre la rubia y la morena, si me gustan ambas?". Espero que no lleguemos a la agria polémica que hubo en la tira 362.)

Lo cierto es que hay, en este país (salvo honrosas excepciones, todo hay que decirlo), una especie de maldición con eso de programar. Incluso con programar bien, que suele involucrar pensar antes de hacerlo y hacer buena arquitectura. Cuando en una gran empresa te nombran arquitecto, parece que te elevas a un mundo de abstracción en el que no deberías volver a tocar un editor de código, no sea que te infectes. Parece como un paso intermedio a la gerencia. Y NO.

Es curioso, porque he visto a algunos malos programadores (no necesariamente malos porque se les diera mal; a algunos, simplemente, no les gustaba) convertirse en malos arquitectos. De esos que tenían un diagrama genérico de un MVC, le cambiaban el nombre y HOP!, proyecto nuevo.

Siempre me ha fascinado (sobre todo, en las empresas grandes), esa manía de separar la arquitectura y la programación, quizá víctimas de la propia metáfora (la del arquitecto y los albañiles). Siempre he considerado ambas cosas dos caras de la misma moneda; No digo que separar tareas no pueda ser una buena idea, pero ese ansia de algunos (malos) arquitectos por desligarse de la programación es simplemente un reflejo de algo obvio; no les gusta programar. Pero, por seguir con la metáfora, un Arquitecto sin conocimientos de programación nunca mataría a Hitler más que en un papel... y un programador sin idea de arquitectura, cogería un rifle y se pondría a disparar en círculos hasta que se le acabasen las balas. Con suerte, con el cañón apuntando hacia afuera ;-)

No sabría decir con exactitud qué me gusta más; ese periodo de perfeccción teórica, diagramas, estimaciones y patrones que precede a un proyecto y que podríamos encuadrar (relajadamente) en el marco del trabajo de un arquitecto o el paso de ponerse a codificar, ver como todo va cuadrando en sus cajitas que has diseñado antes, bellamente... hasta que te encuentras un problema de desarrollo y hay que modificar algo :-). Pero bueno, el mundo no es perfecto, así que su modelado informático tampoco puede serlo. Por lo tanto, yo elijo el trío con la rubia y la morena :-)

P.D: Sí, el CondensadorDeFluzoCrashException está en castellano porque lo de "fluzo" es algo muy español: un errorcillo

P.D.2: El principio de Peter que da nombre a la tira es esto 



¿quieres leer más tiras? Entra en el listado de tiras y escoge!

Puedes usar esta tira libremente,
cumpliendo tan solo esta licencia CC:
Creative Commons License

lunes, 8 de febrero de 2010

132 - Suposiciones (II)


(para leer la tira sin lupa, pulsa en la imagen)



tira relacionada: 33 - suposiciones


Hace un tiempo, a un amigo, en el colegio, le denegaron un premio en un concurso de dibujo porque el trabajo que presentó lo había hecho "con ordenador" y, como todo el mundo sabe, "el ordenador hace casi todo el trabajo".

Hoy en día, ese chico es director de animación de una empresa española que tiene en su haber un largometraje con un premio Goya y que ha producido un cortometraje nominado a los Goya y a los Oscar. Pero claro, supongo que será porque "el ordenador hace casi todo el trabajo".

Casi na.

Esta anécdota viene a resumir lo que mucha gente piensa:

la tecnología es mágica

Atención: rollo ingeniero a partir de aquí:

Esta es una máxima en la que creen con los ojos cerrados muchas personas que quieren soluciones a sus problemas mágicamente; cuando hay una limitación de tiempo, de recursos y/o de conocimientos, la tecnología, mágicamente, puede suplir todo esto y más; haz "flexible" este proyecto; queremos que este software se pueda "adaptar" a multiples plataformas sin esfuerzo; queremos que este software sea fácilmente "ampliable" a nuestras necesidades futuras...

todo eso es precioso, pero...¿para qué necesitas esa flexibilidad? ¿has pensado en qué plataformas tienes como objetivo? ¿qué necesidades inmediatas tienes? ¿qué te planteas en el futuro? ¿puedes hacer una lista de tus necesidades, de lo que quieres que haga el sistema?

Pero pensar es costoso. Y hay gente a la que le debe doler mucho hacerlo.

La mayor parte de las veces, la gente te argumenta que "no hay tiempo para hacer toda esa engorrosa documentación". Argumentan que no pueden detallarte de manera perfecta todo a la primera. Ya puedes decirles que no es eso lo que se pretende, que lo que se busca es un documento inicial, que se revisa y refina, como el software, en sucesivas iteraciones. Es lo mismo. Ellos tienen en su cabeza lo que necesitan, a veces incluso ni siquiera eso; saben que otros tienen esas ideas y se limitan a exigirte que leas mentes. Es curioso como entienden que puede haber varias versiones de un programa pero no de un simple documento.

Otra excusa que se suele dar es que todo eso son "cosas técnicas"; de nada sirve que les digas que son documentos en lenguaje coloquial, en los que hay que decir qué se pretende del software / hardware; documentos en los que se describe como interactua el usuario con el sistema. En cuanto hay un chupachups con brazos al que llamas 'actor' y un recuadrito que se llama 'sistema', ya es algo técnico.

Otra cosa que suele ser el pan de cada día es recibir requisitos 'mínimos' o 'limitados'. El objetivo, loable él, es que des una estimación de tiempo mínima para las funcionalidades básicas de un software y luego soltarte la otra mitad de la funcionalidad. Esto, la primera vez suele producir tirones de pelos, gritos y probablemente, rehacer una arquitectura o desecharla por completo porque a alguien pensó que era mejor no decirte que el sistema debía ser multiusuario, por si te liabas. No entienden que, en realidad, cuanto más grande es un proyecto, más importantes son los cimientos. Y que sin saber lo que se te va a exigir, sin conocer si te van a pedir añadirle 30 plantas al edificio o simplemente que le pongas unas macetas, no puedes decidirlo todo. Y que la palabra 'flexibilidad' no es mágica.

Ya, cuando tienes experiencia, supones que te van a pedir mil cosas y haces una arquitectura tremebunda, con una flexibilidad de mil pares. Y sobrediseñas. Y acabas perdiendo tiempo.

Las señales que os pueden indicar que estáis ante un proyecto indefinido suelen ser:

- La documentación existente está en formato Powerpoint o en documentos sin organización ni estructura; el efecto "carta a los reyes magos".

- Ausencia de glosario de términos. duplicación de conceptos; dos cosas que se llaman igual y son distintas.

- Reuniones maratonianas de varias horas en las que se hacen 'brainstormings' y se definen los requisitos de manera informal, sin plasmarlos en un documento ni asignarlos a nadie específicamente. Se confía en que los que tengan que hacer las cosas sepan que tienen que hacerlas. Usualmente, estas reuniones se repiten en el tiempo, machacando los mismos temas, dado que nadie parece percibir avances; ni los ingenieros perciben necesidades, ni los comerciales / gestores perciben trabajo enfocado a sus necesidades.

Conclusión; lo que no se ha hecho para ahorrar tiempo, se hace durante sucesivas reuniones, sin plasmarlo en documentación, gastando recursos y energía que no sería necesaria de hacer las cosas bien desde un principio; paradójicamente, a pesar de esto, hay gente que cree que hacerlo así es 'más eficiente', dado que 'parece' más trabajo. Es esa misma gente que cree que hacer varias cosas a la vez es más productivo que enfocarse en ellas una a una.

Y al final, lo único que puedes hacer es confeccionar la documentación tú mismo, desde arrancar la especificación de requisitos al 'cliente' hasta desarrollar los casos de uso, definir la arquitectura, hacer el análisis, el diseño, el desarrollo, el despliegue y el mantenimiento. Ser arquitecto, desarrollador, chico de sistemas y atención técnica. Porque no queda otra.



¿quieres leer más tiras? Entra en el listado de tiras y escoge!

Puedes usar esta tira libremente,
cumpliendo tan solo esta licencia CC:
Creative Commons License