domingo, agosto 31, 2008

Me casé con una nerd - Segunda Entrega

Si bien tengo muchos hechos que lo demuestran, voy entregando de a poco....
Este es un chat que tenía por el Sametime con Mecha, obviamente junto con otros 20 y una call de por medio, aca se la ve enojada por que no le contesto o no la endiendo (vaya a saber que).

Eso si, se nota que está estudiando para Sistemas Operativos :)

lunes, agosto 25, 2008

Estimaciones de Software, algunos pensamientos

Ahora que se me rompió la laptop de IBM, tengo un tiempito libre setupeando mi laptop personal (una Dell Latitud D610, viejita pero se la banca) hasta que el soporte técnico se digne a arreglarla. Quería de hablar de un tema bastante heavy del software y siempre trae lindas discusiones en la materia.
El Viernes, con Esteban Lorenzano, antes de dar la charla en Cafelug, nos colgamos hablando del tema y vimos que hay dos cosas totalmente equivocadas o mitos sobre las estimaciones que no estamos de acuerdo para nada, y son:
  1. Querer establecer un modelo matemático para poder justificar un metodo de estimación. Si bien sería algo ideal, es algo imposible (desde nuestro punto de vista) y principalmente por que la unidad de trabajo (ya sea, LoC, UCP, FP, CocomoFuckingFactors) es inmedible, recuerden que la construcción de software es un proceso creativo y no repetible!!! y no solo eso las personas importan y no hay proceso que pueda hacer repetible ninguna tarea de construcción de software.
  2. Los profesionales del software no entienden que quiere decir una Estimación. No quieren entender que es un Pronóstico, una simple (o compleja, de acuerdo a que método uses) predicción del esfuerzo (tiempo, costo y scope) que puede tomar la construcción. Nunca debe tomarse como un hecho, ni tampoco se puede planificar detalladamente y menos que menos controlar en base a una planificación errónea asumiendo estimación... o sea, todo mal. Con lo cual, tomemos el resultado de una estimación como debe ser, algo que nos permita tener una idea y tengamos en cuenta que es errónea desde un principio.
Luego de haber leído un libro muy interesante, les dejo una serie de tips que me gustaron:

  • Separar lo que es un restricción del negocio (para cuando se quiere el software) de una estimación de esfuerzos, son cosas diferentes... no hay que confundirlas.
  • Muchas veces, la estimación es un problema de ineptitud del Equipo que la ejecuta el proyecto. Esto puede ser por falta de comunicación de la estimación y los fundamentos de esa estimación, falta de recursos en tiempo, mal manejo de requerimientos, etc, etc.
  • Hay que tener muy en cuenta el nivel de in/certidumbre por falta de información u otros temas, y eso no solo se mitiga agregando más tiempo a la estimación, sino poniendo el % de desvío correspondiente.
  • Tener en cuenta que el software es algo creativo y depende muuuuuuucho de las personas, y aca se te va la estimación a la mierda, aca es donde hay que estimar "constantemente" por cada iteración para generar un compromiso del team para lograr algo, y eso va ajustando el estimación original que nunca es precisa.
  • Segun McConnel, (opino lo mismo) siempre está mejor sobre estimar que estimar menos de lo que es, ya que estar siempre atras de lo que se estimó genera más ruido, más comunicación, mas reuniones de tracking, mal ambiente que sigue atrasando el proyecto... pero obviamente hay que tener cuidado con la ley de parkinson.
  • No solo se estima tiempo, sino que se estima esfuerzo y costo, ojo aca
  • Las factores son un excelente medio de ir perfeccionando una estimación, pero cuidado con los pesos que se le ponen a dichos factores por que pueden ser comienzo del problema, creo que definir una serie de factores que ajusten la estimación es correcto (no más de 10/15) ya después entra la subjetividad.
  • Está claro que Wideband Delphi es el método que puede tener mejores resultados, pero es muy costoso hacerlo. Y lo que te queda es irte a las estadísticas de la organización para buscar proyectos similares, con tecnologías iguales y dominios similares.

Que lindo sería una materia de esto, no? Aunque prefiero antes que la gente aprenda a construir software como la gente, luego aprender a estimar, asi que todavía tenemos un largo camino que transitar.

domingo, agosto 24, 2008

Que cosas no ayudan al TDD - Revisited

La semana pasada encontré una herramienta muy interesante que mide la testeabilidad de un programa Java y me pareció muy interesante desde el punto de vista arquitectural y seguramente fue esta la que me hizo pensar que evitar a la hora del TDD que dió origen al post anterior. Todavía no la probé, pero en breve seguramente la incluya a mi lista de herramientas que ayudan a sacar métricas interesantes para un arquitectos sobre el código (buen título para un post).

Bueno, la idea de este post era la de contar que el autor (Miško Hevery) de la herramienta tiene un blog super interesante y ya hizo el post un poco más completo que el mio y lo que agregó Pablo (BTW Gracias!).

Me cayó muy bien el tipo de posts, evidentemente odia más el Singleton que yo :)
Bueno era eso, el post van a encontrar otras cosas que no ayudan.

jueves, agosto 21, 2008

Que cosas no ayudan al TDD

Hoy tuve un viaje bastante pesadito de MDQ a BA, 8 horitas, se rompió el auto, llegamos BA a las 19 (o sea todos volviendo del trabajo) y que se yo... en fin estuve pensando en que cosas molestan y mucho al la hora hacer TDD, obviamente tienen más que ver con el el buen diseño y la programación también, estas fueron mis ideas:
Métodos Estáticos
Esta es una de las cosas que más me molesta y sobre todo se vuelve un problema cuando los desarrolladores no utilizan los conceptos de OO y siguen trabajando o pensando en Estructurado. Los métodos estáticos son una mala práctica, realmente no justifico su utilización. Para los que no los notaron, los métodos estáticos son un problema a la hora de querer modificar su comportamiento para poder ejecutar cierto escenario del comportamiento unitesteado, existe varias técnicas para poder evitarlos.
Singletons.
Hay algo para decir aca? Realmente yo a los Singleton los veo como un Anti Pattern, raramente justifico el uso. No solo son dificiles de mokear sino que tambien son muy complicados para unitestear, siempre tenes que caer en agregar un método solo para la hora del testeo.
Service Locators
Piensen lo siguiente, como se implementa un Service Locator, Singleton + Métodos Estáticos, o sea que más puedo decir :) y si, algo más tengo para decir, si bien está claro que IoC es muy superior en terminos de manejo de dependencia y el 60% de los problemas del TDD tienen que ver con el manejo de dependencias, la implementación incorrecta de un Service Locator puede obligarte a no testear absolutamente nada de tu código. Está claro que si se implementa correctamente (no métodos estaticos y no singleton) puede no ser tan malo en terminos de TDD, igualmente dudo que decida utilizar TDD utilice un Service Locator en vez de IoC y DI.

Hasta aquí son las tres cosas que más podrían molestar o en algunos casos fracasar el uso de TDD, y ahora que estoy terminando el post veo que todos tienen que ver con el manejo de la dependencia de objetos... en conclusión, si queres usar TDD y tenes posibilidades de tomar decisiones sobre como se está construyendo un sistema, sinceramente te recomiendo que evites estas tres cosas y trates de focalizarte en como vas a hacer el manejo de dependencias, no estoy diciendo que tengas que usar si o si un IoC framework (cosa que tiene mucha onda en muchos casos) pero si que lo tengas muy en cuenta.

Está claro que lo que acabo de decir puedo asegurar que aplica principalmente con java, todavía quiero ver que pasa con lenguajes dinámicos como Ruby o Smalltalk, creo que no debería cambiar mucho, pero por algo DI no es algo que se usa en Smalltalk, quizá sea o por que son cerrados o realmente no lo necesitan por las características del lenguaje. Es una charla que me debo con Esteban Lorenzano, siempre que intenté tenerla nos fuimos por la tangente. En el caso de Ruby, lo poco que hice la injección de dependencia fue bastante sucia redefiniendo en runtime el comportamiento de las clases, cosa que no está del todo mal, pero prefiero el DI.

miércoles, agosto 20, 2008

Cruzando Fronteras - Jornadas Regionales del CafeLug

Este viernes, con Esteban Lorenzano, vamos a dar nuevamente la charla "Cruzando Fronteras", si, la misma que dimos en el Snoop Update 08' y que? :) Pero esta vez con los amigos del Cafelug en el contexto de las Jornadas Regionales 2008.
Esta es la descripción de la charla para los que nos quieran venir a pelear, insultar, hablar bien de Java o SOA, estamos dispuestos a dar combate.

Título: Cruzando Fronteras - Respuestas revolucionarias a la crisis de las web-applications (Rails y Seaside)
Tiempo estimado de duración: 1 hora
Día, Hora y Lugar: 22 de Agosto, a las 16hs. Universidad de Belgrano, Zabala 1837, Capital Federal
Inscripción: El evento es gratuito pero Inscripción Obligatoria.
Breve descripción de la charla: Cruzando Fronteras, es el resultado de una investigación que intenta analizar el estado actual del arte, en lo que al desarrollo de aplicaciones webdentro de las organizaciones respecta, principalmente en plataformas como Java y .NET, y enfatizar en la crisis que se está viviendo y como respuestas revolucionares en otras plataformas como Ruby y Seaside están ayudando a cambiar y mejorar las arquitecturas actuales de las Aplicaciones Web
Presentación: http://www.slideshare.net/EstebanLM/cruzando-fronteras-respuestas-revolucionarias-a-la-crisis-de-las-webapplications-rails-y-seaside-359454?src=embed

Los espero, creo que esta vez es la última reutilización de la muy interesante investigación que hicimos, no intenta enseñar nada de RoR (que hace mucho que no codeo nada) ni de Seaside, solo compartir unas conclusiones de como creemos que puede venir la mano respecto al desarrollo de aplicaciones web.