Lucas Ontivero : Software Factories

Ruidos y señales en nuestra industria

Lucas Ontivero — Wed, 30 Mar 2011 17:50:00 GMT

Voy a tomar prestado las palabras señal y ruido del campo de las telecomunicaciones para explicar una situación que nos afecta de cerca. Entendamos la palabra señal, en el contexto de esta entrada, como el mensaje, lo importante, lo esencial y como ruido lo indeseable, lo molesto, lo que encarece y entorpece al mensaje.

La señal, o el mensaje en este caso, que deseamos transmitir, por lo general todos los que hemos estado en esto durante algún tiempo (y que nos hemos equivocado terriblemente una infinidad de veces y lo vamos a seguir haciendo), es que educación (léase como entrenamiento o capacitación), trabajo en equipo, orden (o método), comunicación, simplicidad, motivación, experiencia, más experiencia, buen management y buenas prácticas son los puntos claves para el éxito en la empresa de desarrollar software.

El ruido, por otro lado, lo constituyen los maremotos de frameworks que se ponen de moda y cuya vigencia no supera el año o dos, las tendencias y sus variantes (TDD y BDD) y sus productos forzados (Isolation Frameworks, IoC containers/DI) que a su vez son más frameworks o requieren agregar complejidad al código, Patrones y más patrones (alguno de ellos requeridos, utilizados, o introducidos por algunas prácticas o frameworks), nuevos lenguajes con ideas antiquísimas (funcionales y dinámicos), otros lenguajes resucitados (Lisp) y sus mil variantes o dialectos (clojure, scheme y otros), application blocks, ORMs y la lista puede seguir ad infinitum.

Podríamos discutir un año completo el por qué ninguna de estas cosas incrementa el éxito de los proyectos de desarrollo en una forma sustancial. Pero como evidencia podemos recurrir a la realidad cotidiana. ¡Cuidado! No estoy diciendo que todos los frameworks son puro ruido, no estoy diciendo que algunos lenguajes no introducen mejoras, no afirmo que la inyección de dependencia no tiene excelentes usos ni que los patrones, que nos han elevado al grado de que hoy somos más diseñadores que programadores, sean inútiles; NO. No nada de eso, lo que digo es que su contribución al éxito de los proyectos (léase si se quiere como: costos, tiempo, presupuesto y calidad) y en lo que entregamos a los clientes es sencillamente marginal.

En software como en telecomunicaciones, el ruido puede transportar señal también. Esto quiere decir que de todo eso que hoy está de moda, pero que mañana solo servirá para reírnos un rato, algo queda y mucho se aprende.

Mi preocupación va por el lado de la desproporción en la relación señal/ruido. Creo que la señal es débil mientras que el ruido es muy fuerte. Muchas veces por la necesidad de vender productos las compañías introducen gran parte del ruido. Otras veces, somos nosotros cuando resaltamos el ruido cuando buscamos gente “Perfil: deberá conocer WCF, Mockito (conocimiento de Moles se tomará en cuenta), Prism, MVVM, Unity, Linq, JQuery y controles de Tellerik”. Esto amplifica el ruido tremendamente. Al cliente por otra parte seguramente le entregaremos una solución bastante parecida a lo que le hubiésemos entregado hace 3 años cuando ningunas de esas cosas existía.

Otro ejemplo de DSL en el mundo real

Lucas Ontivero — Fri, 27 Aug 2010 03:31:44 GMT

Desarrollo un sistema para la planificación, ejecución y seguimiento de encuestas en el que uno de los requerimientos es poder crear encuestas de manera sencilla y veloz. Además las mismas deben seguir un workflow (algo informal) de revisión. Otro dato importante es que el cliente diseña encuestas que van desde aquellas con solo algunas pocas preguntas hasta esas otras que nos tienen todo un domingo respondiendo acerca de alguna ginebra o algún nuevo centro comercial. Para rematar debo decir que...(read more)

Escalando DSL internos

Lucas Ontivero — Mon, 16 Aug 2010 18:08:35 GMT

En mi entrada Fluent Interfaces y TDD presentaba una prueba de concepto sobre un DSL interno que estaba desarrollando para encapsular varios detalles de la manipulación de documentos en el proyecto en el que trabajo actualmente. Luego de avanzar un tanto me doy con un problema muy común en la mayoría de las interfaces fluidas que he visto, a este patrón lo llamo sentencia única . Esto significa que una sentencia de un dsl interno no interactúa con otras del mismo. Veamos un ejemplo: Dh.Using.AnimalControl...(read more)

Qué debemos considerar antes de crear nuestro DSL

Lucas Ontivero — Sun, 15 Aug 2010 23:36:03 GMT

Hoy todos reconocemos el potencial que tiene (LOP) Language Oriented Programming, pero no solo eso sino que muchos ya están invirtiendo para hacerse con las ventajas prometidas por este paradigma(?). Muchos incluso diseñan la sintaxis de aquellos lenguajes que entienden, pueden hacerles alcanzar la productividad, calidad y mantenibilidad que buscan. Ahora bien, una vez decididos a crear el lenguaje (textual) propio para un dominio particular, hay que implementarlo. Aquí es donde deben estudiarse...(read more)

[Unit Tests] Contras de implementar test unitarios

Lucas Ontivero — Tue, 29 Sep 2009 00:46:21 GMT

He querido compartir en este video de 7 minutos mis experiencias con la implementación de test unitarios cuando la inversión en capacitación es escaza. Que peligros encierra una pobre capacitación y ante que escenario nos podemos encontrar es de los objetivos de este video. Lucas Ontivero...(read more)

[Patterns] Patrón Visitor Explicado (Parte 2 - Final)

Lucas Ontivero — Mon, 25 Aug 2008 18:56:00 GMT

Esta es la segunda (y última) entrega de la explicación en video del patrón de diseño Visitor....(read more)

[Patterns] Patrón Visitor Explicado

Lucas Ontivero — Wed, 20 Aug 2008 03:51:00 GMT

Esta es la primera parte de la explicación de este patrón. Uno de los patrones más lúcidos.Este es el último que grabo en sesiones nocturnas así que ya no me van aoir susurrando :) Lucas Ontivero...(read more)

Análisis estático de código y malos diseños

Lucas Ontivero — Tue, 19 Aug 2008 13:47:00 GMT

Aprender a desarrollar y a diseñar software es una tarea en la que hay que invertir muchos años. Hay que ser obsesivo, fanático, hay que equivocarse miles de veces y aprender de esos errores. No contentarse con los aparentes aciertos porque al poco de andar se descubre que no se hizo lo mejor sino que alguien más en un blogs perdido en la web lo resolvió mucho mejor que nosotros y ese alguien también encontrará mejores maneras 10 minutos después de su posteo. Pero sobre todo, hay que leer muchísimo...(read more)

[Patterns] Factory Method Explicado

Lucas Ontivero — Thu, 31 Jul 2008 04:55:00 GMT

Patrón Factory Method explicado paso a paso con un ejemplo clásico. Para una mayor calidad de imagen pueden este video desde hosteado en SoapBox desde el siguiente link: http://video.msn.com/video.aspx?vid=2c151d4f-70a1-44b3-97ad-23c4f222dd98 Lucas Ontivero...(read more)

[Patterns] - Patrón Singleton explicado

Lucas Ontivero — Sun, 27 Jul 2008 06:07:00 GMT

Patrón Singleton explicado - parte 1 Patrón Singleton explicado - parte 2 Patrón Singleton explicado - parte 3 Lucas Ontivero...(read more)

[PM] Estimaciones y Scheduling Avanzado

Lucas Ontivero — Wed, 12 Mar 2008 08:31:00 GMT

En este artículo vamos a ver una rápida introducción a la estimación de tamaño, esfuerzo, tiempos total, costos y optimización (compresión) de schedule utilizando simulaciones mediante el método de Monte Carlo. ...(read more)

[Languages] Mi lenguaje de programación (Parte I - Ideas)

Lucas Ontivero — Tue, 11 Dec 2007 00:57:59 GMT

Hace algún tiempo que vengo pensando y me vengo autoconvenciendo de que el nivel de abstracción que normalmente se utiliza en el desarrollo de aplicaciones dirigida por los datos no es el adecuado. Este tema ya lo toqué en otros post sobre Domain Specific Language y sobre Software Factories así le doy una vuelta más de rosca y presento mi lenguaje de programación. Veamos como se desarrolla un software: Nos llegan los requerimientos de nuestro Program Manager/Team Leader y, después de las reuniones...(read more)

[Software Factories] Introducción (Parte 4)

Lucas Ontivero — Tue, 02 Oct 2007 21:10:44 GMT

Esta entrada es parte de la serie "Introducción a los conceptos de Software Factory" que hasta el momento se compone de las entradas anteriores: [Software Factories] Introducción (Parte 1) , [Software Factories] Introducción (Parte 2) y, [Software Factories] Introducción (Parte 3) En esta entrada voy a trara sobre el punto central al que aplica el concepto de SF, la linea de productos. Antes de esto debo aclarar que existe una clasificación de los SF la cual distingue entre SF horizontales...(read more)

[Software Factories] Introducción (Parte 3)

Lucas Ontivero — Sun, 30 Sep 2007 05:33:27 GMT

Voy a continuar aquí la serie "Introducción a los conceptos de Software Factory" que comencé en mi blog anterior con las entradas: [Software Factories] Introducción (Parte 1) y, [Software Factories] Introducción (Parte 2) Me permito taer aquí un fragmento de un post anterior para definir el concepto: <cita> Software Factory Si se le hubiese llamado de otra manera nos habriamos visto forzados a realizar un esfuerzo mental para averiguar y tratar de entender de que se trata este concepto...(read more)