blog de luxspes

Primeramente, pensé que el truco tenía que encontrarse en el concepto de economía de escala, los tostadores, refrigeradores, etc, son menos costosos por que se producen en grandes cantidades. Claro, eso explica por qué es más barato comprar un tostador que construir uno por mí mismo, pero ¿Qué pasa con el software que construyen las consultoras? ¿Aplica ahí el mismo principio? ¿Y con el software de procesador de textos que podría estar usando para escribir esto?

Hace ya unos meses, me encontré por casualidad con que @Domix había twiteado la dirección hacia un “rant” (¿una perorata?) de Zed Shaw (el creador de Mongrel) en la que despotrica sobre todo lo que le molesta de la comunidad alrededor de Ruby on Rails. En lo personal, yo no soy desarrollador de Ruby, ni de Rails, y aunque la perorata de Shaw me pareció, como a muchos de los que la leímos ese día, interesante, no fue por sus quejas sobre esa comunidad si no por algo que comenta más adelante:

Where I work the company is willing to blow huge amounts of money on a consulting firm or hardware, but ends up firing people when times get tight. It’s a universal mass hysteria that paying $100 – $200 per hour for a group of consultants is preferable to simply hiring good employees. At the rates companies pay these consultants they could hire 4 full time employees.

El Lab PLC, la nueva área de innovación cívica y creatividad urbana del GDF, convoca a los ciudadanos con habilidades técnicas de programación, desarrollo tecnológico, diseño interactivo y afines, así como universitarios o egresados recientes que estén interesados en colaborar con el gobierno para encontrar soluciones creativas en estas áreas: desarrollo económico, medio ambiente, salud, transporte y turismo.

A través de Código para la Ciudad de México, los Programadores Ciudadanos y Universitarios seleccionados, en conjunto con las secretarías participantes identificarán necesidades y áreas de oportunidad para después proponer y desarrollar aplicaciones y otras soluciones digitales creativas.

Perfil deseado:

1. Interés en colaborar con el gobierno para proponer soluciones digitales a los retos de la ciudad.
2. Experiencia y habilidad para programación digital, creación de aplicaciones móviles y web.
3. Contar con un equilibrio entre las habilidades técnicas y la experiencia en áreas de gerencia (comunicación, manejo de proyectos, entre otros).
4. Disponibilidad de tiempo completo durante los 9 meses del proyecto, del 2 de septiembre de 2013 al 31 de mayo de 2014.

El sábado pasado asisti al taller de Ceylon, en el taller vimos diferentes temas: Conceptos básicos, Clases, Manejo de Nulos, Uniones e Intersecciones, Funciones, Iterables

En la sección de Conceptos Básicos vimos al típico hola mundo:

En Ceylon un programa es simplemente una función de primer nivel sin parámetros.

Vimos que cuando una funcion sólo devuelve una expresión, se puede abreviar usando la "flecha gorda"

Y tambien nos introdujeron a los parametros variadicos (los que pueden aceptar multiples valores):

Una de las caracteristicas mas interesantes de Ceylon es que puede inferir el tipo de una
declaración local.

…escuchó a un maestro que estaba enseñándole a una niña a tocar un instrumento de cuerda. Dicho maestro le dijo que si la cuerda estaba muy floja no sonaría, pero si la cuerda del se encontraba muy tensa se rompería: la cuerda debía estar en su justa tensión para que pudiera dar música y armonía. En ese momento comprendió el camino medio…

En la parte anterior de esta serie, les relate sobre YAGNI y OAOO y les dije que OAOO y YAGNI son como el Ying y el Yang. Se balancean. Sin OAOO, YAGNI lentamente nos estrangularía. Con OAOO, siempre tienes un sistema que puedes mejorar (frase de Ron Jeffries).

Yo también amarraba al gato, construía los sistemas como veía que los construían los demás, estaba en el nivel Shu de ShuHaRi a la hora de programar sistemas empresariales, ponía mis DAOs, ponía mi Servicio y ponía mi Controller.

Todos los sistemas “bien arquitectados” que conocía lo hacían, asi que lo hacia yo también. Si un sistema bien arquitectado se ve así al final, debe ser por que se veía así desde el principio… ¿no?

El maestro de zen y sus discípulos comenzaron su meditación de la tarde.El gato que vivía en el monasterio hacía tanto ruido que distrajo los monjes de su práctica, así que el maestro dio ordenes atar al gato durante toda la práctica de la tarde.
Cuando el maestro murió años más tarde, el gato continuó siendo atado durante la sesión de meditación. Y cuando, a la larga, el gato murió, otro gato fue traído al monasterio y fue atado durante las sesiones de práctica.
Siglos más tarde, eruditos descendientes del maestro de zen escribieron tratados sobre el profundo significado espiritual de atar un gato para la práctica de la meditación

Hace algunos años asistí a un evento que Sun organizo para promocionar Java aqui en Mexico (Java Dev Days creo que se llamaba). En aquel entonces entre a una presentacion, creo que era de Sang Shin (el creador de JavaPassion) en la que explicaba lo simple que era utilizar JRuby con Ruby on Rails para crear una pagina de “hola mundo”. Era algo mas o menos como este video: http://www.youtube.com/watch?v=sas3KCKwyHI. Era la primera vez que veia a RoR asi que por ese lado me parecio educativo… sin embargo, la mayor parte de audiencia… se estaba durmiendo!

Una petición (que a menudo se convierte en exigencia) muy común que hacen los clientes, es una garantía de desempeño, cosas como:

1. Quiero que todas las pantallas/paginas tengan un tiempo de respuesta máximo de 3 segundos.
2. Quiero que todas las consultas tengan un tiempo de respuesta máximo de 3 segundos
3. Quiero que el sistema corra en mi servidor (cuando bien nos va, nos dicen las características del servidor)

Que hacer en un caso así? Cuando yo acababa de salir de la carrera (hace ya más de una década) mi respuesta solía ser: "Necesito más datos", "Con la información que tengo no puedo garantizar ese desempeño", "No sé ni en que consiste el algoritmo para el proceso de cálculo de comisiones por ventas indirectas ¿cómo voy a garantizar que la pantalla donde veo el resultado de eso responda en 3 segundos???"

Casi sobra decir mi actitud era la actitud equivocada...

En ingles hay un dicho: There is a difference betwee doing the right thing and doing the thing right.
La traduccion directa seria algo asi como hay una diferencia entre hacer lo correcto y hacerlo correctamente.

En la estimacion de software, y el proceso de negociacion que es necesario para que una consultora le
construya software a un cliente la diferencia entre una cosa y la otra es tremendamente importante.

Para "Hacer lo correcto" debemos entender claramente que es lo que el cliente realmente necesita (independietemente de lo que pida), en cambio, para "Hacerlo correctamente", no es relevante si lo que hagamos realmente le va a servir al cliente o no,lo que es importante es si lo que hicimos esta bien construido.

Un ejemplo extremo:

Un cliente viene y te describe un vehiculo monoplaza de transporte, que le permita viajar a donde quiera. Tu le de construyes una bicicleta, el pensaba usar el vehiculo en alaska, en la nieve, buscaba: una motonieve.

Finalmente, no importa que te tan bien hayas construido la bicicleta (hecha correctamente) al cliente no le sirve, por que lo que el necesitaba (hacer lo correcto) era que le construyeras una motonieve.

Antes de continuar con mas ejemplos concretos de supuestos, considero importante relatarles que cuando iniciaba con desarrollo de software me tope muchas veces con esta situación:

Lider del proyecto: El cliente dijo que la caracteristica XXX no le parece util. Que no entiende por que la hicimos asi si el necesitaba otra cosa
Programador: Es que yo supuse que...
Lider del proyecto: Pues, para la proxima vez no supongas: pregunta!
Programador: Lo siento, no vuelve a pasar

Y unos dias despues:

Programador: ¿Como debemos hacer la caracteristica YYY?
Cliente: Pues, de modo tal que maximisemos la eficiencia y demos valor al negocio...
Programador: Si, pero, la multiplicidad entre productos y pedidos es uno a muchos? o muchos a muchos?
Cliente: (de que habla este compadre?) Lo siento, tengo otra junta, luego lo vemos
Programador: Pero pero...

Y finalmente:

Hace poco lei, un tweet que decia:

Felicidades a "Asumir" por ser la MADRE DE TODOS LOS ERRORES DE ESTIMACIÓN en los desarrollos de software!!!!

— SoftwareEvangelist (@vanessa_amaya) May 10, 2013

¿se dara cuenta la autora... que esta asumiendo que asumir es el problema?