viernes, 16 de diciembre de 2011

Vuelta al Blog y algunos consejos para la carrera

Cambios de Empresa, Viajes a Shanghai, a Palo Alto, en el mismísimo Silicon Valley, construcción de plataformas para Cloud Computing, uso intensivo de Git, GitHub, continuous Integration (Integracion Contínua), implementacion de Continuous Deployment (Despliegue continuo), Culturas de Start Ups, etc., son algunas de las novedades de este año que ya se termina. Son demasiadas para un solo post. Vamos a ir retomando de a poco este espacio de reflexión sobre tecnología de la información, buenas practicas de Desarrollo y todo lo que hace a las metodologias ágiles y al desarrollo de software en general.

La verdad es que tuvimos un poco abandonado (tachen "un poco") a este blog gran parte del año. Hemos estado envueltos en un proyecto altamente demandante de tiempo en una empresa Start Up. Algún día con un poco mas de perspectiva escribiremos sobre esta experiencia que ha tenido de TODO menos aburrimiento. En parte es por eso que no hemos podido escribir en este blog. Estuvimos en unos de esos periodos de aprendizaje intensivo, mezclados con no-pocos-cambios y experiencias de toda índole. Y todo suceso de este estilo conllevan un ritmo que no dan mucho margen para pararse a pensar y reflexionar demasiado sobre lo que esta sucediendo.

Hoy quiero dejarles esta reflexión.

Cuando recién empezaba en esta profesión (hace poquísimos años....bueno tampoco tantos che! unos 16 añitos...) no había la diversidad de ofertas que hay en este momento. Uno elegía entre dos o tres opciones a lo sumo e iba pasando de proyecto en proyecto mas o menos como y cuando podía. Tampoco me importaba demasiado porque en ese momento pensaba (no lo pensaba, en verdad, lo "sentia" de alguna manera porque si me paraba a pensarlo es obvio que no es asi) que tenia infinitos proyectos por delante.

Habiendo ahora tantos proyectos, tantas empresas y ofertas dando vueltas por el mundo veo a un montón de gente que se conforma con lugares mediocres, con proyectos tan interesantes como palear las arenas del Sahara en verano y se aferran a trabajos malsanos o ambientes enfermos como si estuviéramos hace 30 años atrás donde un empleado entraba a una gran empresa y sabia que se iba a retirar en ella.

Por el otro lado veo tambien a chicos muy jóvenes, con mucho empuje y ganas pero que en lugar de elegir lugares adonde aprender, repito: adonde r-e-a-l-m-e-n-t-e aprender, van saltando de trabajo en trabajo como sapo perseguido porque un trabajo le ofrece 10 pesos mas que otro, sin planificar a mediano plazo. Sin planificar en que área, en que tipo de proyectos le gustaría trabajar. La gente que trabaja en IT en USA tienen muy claro esto de planificar sus carreras a mediano plazo digamos.

Muchas veces he tenido que elegir entre proyectos. A veces entre ganar mas plata y hacer algo que me interese. Elegir entre el bolsillo o el corazón. Y créanme lo que les digo, las veces que elegí con el bolsillo... nunca salieron como esperaba.

No estamos planteando acá una postura romántica o naif o a la San-Francisco-De-Asis, "Salven al mundo!! Sigan sus corazones", "Viva la pobreza", "Si a la Revolución Arabe", no (es decir, Si a la revolución Arabe pero no a Vivir en la pobreza ). Sabemos que uno trabaja principalmente por dinero y que lo que busca en general al cambiarse de trabajo es un crecimiento...en dinero.

Pero lo cierto es que si es "solo" el dinero, si el trabajo no te motiva, es aburrido o te desmotiva a cada paso, tarde o temprano terminarás odiando lo que haces, o a tus compañeros o jefes o a todos juntos... incluyendote. Y 40 horas semanales (o mas!) es demasiado tiempo para hacer algo que uno odia, verdad?.

Asi que les dejo la GRAN VERDAD NUMERO 1 de este fin de año, a modo de reflexión.

GRAN VERDAD NUMERO 1:

Hay un numero limitado de proyectos de desarrollo en los que participaremos en nuestras vidas. Elijamos aquellos que realmente nos apasionen. Somos de los poquitos profesionales en el mundo, los de IT, que podemos darnos este lujo.

Asi que, aún cuando esten recien comenzando la carrera, y sobre todo si estan en esta situacion, empiecen por pensar que quieren, que les gusta. Que les gustaria hacer los proximos años.

  1. Si solo conocieron un lenguaje de programación, experimenten con otros.
  2. Si solo estuvieron en consultoras de sistemas, traten de estar en el depto de sistemas de una gran empresa.
  3. Si solo estuvieron en un determinado tipo de proyectos o metodología, experimenten con otros.
  4. Traten de cambiar a proyectos que sean interesantes, por la tecnología o por el tema de negocio relacionado.
  5. Traten de rodearse de personas que sepan mas que ustedes.
  6. Empiecen un blog de sus temas favoritos, participen en foros,
  7. Hagan de su CV un diamante en bruto, al cual agreguen items puliendolo asi dia a dia.

Y si hacen algún trabajo que realmente los apasiona, si son buenos y se esfuerzan cada dia por mejorar, por crecer profesionalmente, si se preocupan y toman cada nuevo comienzo como una gran oportunidad, y piden reconocimiento (noten que no dije "esperen reconocimiento"), créanme, va a suceder. Van a ganar dinero y hacer algo que les apasione.

Elijan siempre con el corazón.

viernes, 20 de mayo de 2011

El sindrome de Estocolmo II : Test para saber si te han Secuestrado

Hablabamos en el post anterior de que en la actualidad hay muchisimo trabajo y oportunidades laborales en el área de sistemas y sin embargo es frecuente encontrar a personas muy capaces e inteligentes sufrir por sus trabajos actuales, quejarse constantemente pero no encontrar una salida y quedarse en un circulo vicioso.

Las siguientes son las condiciones de contexto adonde es probable que se produzca un síndrome de Estocolmo. Agregamos algunas preguntas que tiene que ver específicamente con las situaciones que se producen al trabajar.

Si estas trabajando hace rato en un mismo trabajo, si te sentís desmotivado, aburrido, hastiado. Si te enfermas a menudo, si hay ciertas cosas que te rebelan. Si tenes miedo de expresar lo que sentis, lee las siguientes preguntas y contestalas por y para ti.

A - Debe existir la percepción de una amenaza cierta a la supervivencia o integridad física o mental del Rehén.

Los empleadores tienen el poder de decidir si lo despedirán a uno, si le darán una promoción a un cargo mayor o decidir si lo asignara a un proyecto importante o irrelevante.

La amenaza aquí, ciertamente no de vida (al menos en los casos que conozco) se produce porque el empleado ve amenazado sus ingresos, su carrera, su futuro en manos de la decisión de uno o mas de sus empleadores.

Se ha generalizado la sensación de que no se debe criticar ni se puede estar en disenso?. Hay rumores de que tal y tal personas fueron echadas por ese u otro comportamiento que la empresa desea desalentar?. Hay alguna que otra humillación privada o más o menos pública o falta de consideración total. Hay rumores de que solo acomodado o siendo amigo de alguien se consiguen ascensos? Todos tus compañeros trabajan horas y horas de más y te miran mal cuando trabajas solo 10 horas diarias?

Repetimos lo que dijimos en el post anterior: No en toda empresa simplemente por existir la posibilidad de un despido se esta en esta condición, porque entonces se cumpliría en todos lados. Estamos refiriéndonos a aquellas adonde la amenaza se cierne siempre, de manera constante, de una manera más o menos explicita o velada en conversaciones, rumores de pasillos y en la publicidad de las "ejecuciones" (cuando se despide a alguien).

B - Aislamiento del exterior y único contacto con opiniones y perspectivas de los captores.

Esta condición se cumple en general en grandes corporaciones o empresas con una cultura interna muy fuerte. Los empleados viven inmersos en ese "mundo", solo reciben la visión de sus empleadores, jefes y compañeros. Una de las características principales que se da es la creencia generalizada de que la situación en esa empresa es "especial", distinta al resto del mundo y que en ningún lugar se hacen las cosas mejor que allí. Las pequeñas bondades de la empresa se magnifican y personalizan.

La mejor y única tecnología es la que se usa en tu empresa y el resto son basuras? Casualmente los de adentro son las mejores personas y la empresa tiene los mejores resultados? No tenes idea de cuanto se paga en el mercado? Cuan buscado es tu perfil? Siquiera que tecnologías se usan en otras empresas? No te dejan ir a seminarios o cursos? Se desmerecen con comentarios despectivos reuniones de asociaciones o grupos independientes?

C - Pequeños actos de bondad y cuidado de los abusadores a las victimas.

La empresa instala Aro de Baskets y Play Station? Pone una maquina de Golosinas y gaseosas para todos? Te otorga un salario un poco por encima del promedio para el cargo? Súbitamente aparecen pequeños bonos o premios de distinta índole? Que tal ese beneficio adicional que estabas esperando? Uno siente que aun cuando el ambientes de trabajo es malo, desmotivamente, la empresa intenta ser buena con uno dándole algunas pequeñas ventajas materiales. La sensación general es "Es verdad que esto es un desastre pero...por lo menos me pagan bien".

D - La percepción de la imposibilidad de escapar del abuso.

Los empleados atrapados en estas empresas perciben "barreras de salida" alrededor de ellos que no los dejan "escaparse". En cierto sentido son excusas pero excusas bastante reales. Veamoslas.

Tu sueldo es bien alto y competitivo de manera que otras empresas en tu mismo cargo no pueden pagártelo? Los beneficios son tan intrincado de medir que no sabes realmente cuanto pedir para pasar a otra empresa? Estas desarrollando tareas no habituales para tu experiencia o encerrado en tecnologías muy puntuales que hacen que no puedas encuadrarte realmente en un perfil para salir a buscar trabajo? Vas a una y otra y otra entrevista pero siempre el aura de beneficios de tu empresa actual hacen que no termines aceptando nunca otra propuesta?

Como leer los resultados del tests?

Muy simple, si contestas que sí a algunas o varias de las preguntas en los apartados A, B, C y D podes estar viviendo un cuasi-Sindrome de Estocolmo.

Asi que ya saben, si sos programador y a pesar de ganar muy bien o tener ciertos beneficios, te sentis realmente mal en tu trabajo, si te estresas, te agarras pequeñas enfermedades frecuentemente y no te animas a buscar un nuevo trabajo (o ninguno te viene bien), recordá lo siguiente:

En el Yoga tradicional se sostiene que para que entre algo nuevo en tu vida tenes que vaciarte, tenes que eliminar todo lo viejo, sino, justamente ese aferrarse al pasado no permite que entre nada nuevo, no deja cambiar, no permite crecer.

No sera hora entonces de pulir ese CV en Linkedin ?

martes, 10 de mayo de 2011

El sindrome de Estocolmo



En estos últimos años he estado en contacto con varios colegas de área de desarrollo de software que no están bien en sus respectivos empleos pero por algún extraño motivo se resisten a abandonarlo. Se quejan del ambiente, de algún jefe, de las herramientas que utilizan, de las horas que tienen que trabajar de más, caen enfermos con frecuencia, sufren muchas contracturas, engordan, en pocas palabras, sufren, pero aun asi no atinan a cambiar de trabajo.

No se si es algo aplicable a toda latinoamérica, pero aquí en Argentina, en estas épocas de bonanza, adonde la demanda de determinados perfiles supera amplia mente a la oferta eso es un poco... ilógico.

Aclaramos, no estamos diciendo que ante el primer pequeño problema o desmotivación hay que irse del trabajo. No, no es asi. Para ser claros, no estamos de acuerdo con el típico programador que salta de empresa en empresa, quedándose 3 A 5 meses antes de escapar a otra para evitar asumir cualquier responsabilidad o ganar dos centavos más.

Contexto laboral para el surgimiento del síndrome

Las situaciones a las que me refiero son bastante más enfermizas y de cierto maltrato. Esto no significa que los esclavicen con látigos o trabajando a destajo (eso se terminó hace algunos pocos años, jeje), no. Son maltratos mucho más sutiles.

En algunos casos se comienza por instalar una atmósfera rancia de presiones por alinearse con el proyecto en particular de una o varias personas. Surge luego un ambiente ligeramente amenazador adonde nadie se anima a decir en voz alta lo que piensa y termina con la instalación de amenazas veladas sobre que no estar de acuerdo implica despidos o degradaciones / humillaciones publicas o de cargos.

En otras empresas en cambio se da por una falta total de motivación causada por peleas políticas en las altas esferas que hace que cualquier proyecto se paralice y cambie de dirección mil veces antes de ser abandonado sin terminar, lo cual causa desmotivación, falta de interés seguido de aburrimiento y terminando en hastío.

A veces son simplemente ambientes estatales faltos totalmente de desafios e incentivos y en otras se generaliza la desmotivación cuando se premia cualquier cosa menos trabajar bien.

A quienes Afecta?

Son Programadores, Analistas, Arquitectos, personas capaces y responsables, viven quejándose, desmotivados, malhumorados, con cansancio crónico pero sin embargo no se dan cuenta que pueden irse de esas empresas. O cuando lo intenta, no alcanzan nunca a encontrar el trabajo ideal, ese que están esperando para irse.

Condiciones para la aparición del síndrome

Hace cierto tiempo había leído un articulo de Chad Fowler titulado : "Dead-End Jobs: Are You Suffering From Stockholm Syndrome?", el cual me pareció ciertamente un tanto exagerado. No obstante, ahora releyéndolo encuentro algunas similitudes ciertamente inquietantes.

En psicología el termino "Síndrome de Estocolmo" es utilizado para describir un comportamiento psicológico paradójico adonde un rehén desarrolla empatía y sentimientos positivos hacia sus captores.

Pueden leer el post de Chad Fowler que describe, seguramente mejor de lo que yo lo haré, las condiciones que se cumplen para que esto suceda en "Dead-End Jobs: Are You Suffering From Stockholm Syndrome?".

Fijense entonces las condiciones y después ustedes sacarán sus propias conclusiones.

A - Debe existir la percepción de una amenaza cierta a la supervivencia o integridad física o mental del Rehén.

B - Aislamiento del exterior y único contacto con opiniones y perspectivas de los captores.

C - Pequeños actos de bondad y cuidado de los abusadores a las victimas.

D - La percepción de la imposibilidad de escapar del abuso.

El punto 3 es esencial toda vez que si la conducta de un Captor hacia su victima es de violencia y agresión permanente el Rehén desarrollara odio o terror pero nunca se encariñará. Tiene que haber pequeños actos de bondad o que sean percibidos como tales para que la victima al tratar de evitar el miedo o el pánico se refugie en esos pequeños actos para protegerse mentalmente del miedo, de la perdida de control de su vida y del ataque a su autoestima.

Existen realmente los Trabajos-Captores?

Repito que a mucha gente, yo el primero, puede parecerle una exageración hasta aquí la relación entre sentirse atrapado por un trabajo y condiciones de secuestros reales adonde lo que esta en juego es la vida de la persona secuestrada. Pero si uno mira una a una las condiciones se pueden ver algunas similitudes.

Creo que es importante aclarar un poco mas sobre las condiciones que hacen que un empleo en particular tenga este efecto.

Como nos debemos a nuestra audiencia, para la proxima, prometemos desarrollar un mini-test de preguntas para ayudarnos a analizar si ese trabajo que te está haciendo pasarla mal te ha capturado, y lo peor es que no esta pidiendo mas rescate que tu salud.

miércoles, 20 de abril de 2011

Lecciones reaprendidas

Hoy tuve unas de esas peleas con el código que te hacen reconsiderar el pasarte a Management :). No fue muy sangrienta, sólo un bloqueo de media hora, pero cometí tantos errores repetidos que cuando finalmente logré hacer lo que quería no sentí satisfacción sino bronca.

Mi objetivo era hacer una subclase de una clase básica del entorno, para agregarle cierta funcionalidad. Estaba apurado porque tenía poco tiempo y quería terminar esta tarea hoy. Intenté el camino obvio: crear la subclase y utilizarla en lugar de la clase del sistema. Esto no me funcionó y como estoy en un entorno bastante nuevo (Objective-J/Cappuccino), decidí que la herencia no debía estar funcionando bien (??). Entonces me puse a buscar maneras de lograr mi objetivo de otra manera: intenté con un wrapper de la clase que quería modificar, con modificar el comportamiento de la clase que llamaba a la nueva clase y con unas cuantas maneras más, sin resultado. Busqué un rato en Google, pero no encontré ninguna referencia a mi problema. Estaba atascado. Ya perdido, volví a intentar el camino inicial, y funcionó!!. Revisé lo que había hecho en mi primer intento y por supuesto, encontré un problema en mi implementación inicial.

Los errores que cometí fueron los siguientes:

1. Asumir que la herencia no funcionaba. El compilador nunca está roto!!! Bueno, si, a veces está roto, pero en 20 años de programar sólo he descubierto 2 o 3 de esos errores y me he equivocado muchas veces. Es siempre mucho más probable que el error este entre el teclado y la silla.

2. Trabajar apurado. Quería terminar hoy y dejé que el apuro dominara mi forma de trabajar. Al final me llevó más tiempo que si lo hubiera hecho tranquilo.

3. No hacer un experimento. Si sospechaba que la herencia estaba andando mal, tendría que haber armado una clase sencilla y probar las cosas ahí. Si no lograba reproducir el problema, probablemente hubiera sospechado la verdad...

4. Insistir en arreglar el código que había hecho. Cuando uno no encuentra un error que obviamente tiene que estar ahí, lo más sencillo es borrar las modificaciones y empezar de nuevo. Tengo la costumbre de hacer commits muy frecuentes, así que volver atrás mis cambios no hubiera sido costoso. Además, estoy usando git, asi que también hubiera podido volver atrás temporariamente con un git stash.

5. Trabajar sólo. Este fue exactamente el tipo de problema que haciendo Pair Programming no me hubiera pasado.

Bueno, ahora que lo escribí se me pasó un poco la bronca... la próxima vez que sospeche del compilador espero acordarme...

lunes, 18 de abril de 2011

Calidad III : La Relatividad del concepto

En los comentarios del post sobre la Calidad del Desarrollo de Software II tanto Walter Risi comoErnesto Kiszkurno aportaron un par definiciones distintas y muy interesantes de la calidad de software.

El concepto de la calidad de Software, en general, es decir Que hace que un software sea de calidad es uno de los temas que más discusión ha causado dentro de la comunidad de sistemas desde hace décadas.

En los 2 posts anteriores sobre Calidad del desarrollo hemos evitado justamente este tema ateniéndonos nada mas (pero nada menos) que al concepto, bastante más concreto, de que es lo que hace que un desarrollo sea de calidad. Es decir, para usar la metafora-que-odio-de-la-fabricación, que calidad tiene su construcción, su Calidad Interna.

Pero para no esquivar el bulto al problema más general, podemos plantearnos entonces , Que determina que un software sea de calidad?

El Juego

Uno de los sistemas que más utilizamos en nuestra época de estudiantes en Exactas (UBA) fue un juego (como no podía ser de otra manera) de estrategia en tiempo real llamado Dune II. Fue un juego que nos apasionó y en el cual podíamos pasarnos horas jugando hasta terminar las misiones. No obstante ese juego tenia un par de bugs molestos, uno de ellos con la Inteligencia Artificial de la maquina que justamente en determinadas situaciones no respondía bien en la defensa y el otro con el manejo del gusano de arena que ha veces se tildaba y quedaba ciclando en algún loop escondido.

Si nos hubieran preguntado allá en el tiempo pero incluso ahora que opinabamos de la Calidad de ese desarrollo, creo no exagerar en decir que era Sobresaliente, excepcional.
Hubiera agregado algo si la empresa dueña del juego arreglaba esos bugs? Probablemente hubiera sido lindo, quizás un poquito mas interesante pero....eso no hubiera cambiado la percepción de la Calidad del producto que teníamos, era sencillamente de Calidad.

Entonces, que es lo que determina que un producto de software sea de Calidad....y bueno... si no queda otra, ensayemos algunas respuestas habituales:

1) que sea utilizado por mucha gente?

Windows es el caso arquetípico de software utilizado por mucha gente que no obstante....digamos que jamás ha sido famoso por su Calidad (piensen sino en el caso cercano del Vista y ni que hablar de otros...ejem fallidos como ....alguien se acuerda del Milleniun?)
El software de Mac en general tiene asociado una fama de mucha mayor Calidad y es utilizado por muchisima menos gente.

2) que sea fácilmente usable?

El problema para determinar aquí que tal sistema es de Calidad por su usabilidad, más allá de los recientes libros y normas sobre usabilidad de Diseñadores gráficos, es que los usuarios tienden a encariñarse poderosamente con la interfaz de usuario que conocen. Siempre prefieren lo conocido por sobre lo novedoso.
Piensen sino en lo que diría un usuario de WordStar o WordPerfect si tuviera que usar el Word actual o, viceversa, si un usuario de Word tuviera que usar el Wordstar y para ambos la usabilidad de la herramienta que usan/usaban era formidable. Ni que hablar de la pelea entre los amantes de Vi versus Emacs versus editores de linea tradicionales.
Para los amantes de linux cualquier linux es totalmente fácil de usar pero si le damos una consola de comandos a una persona que siempre uso Windows...bueno...inmaginense su juicio.

3) que Tenga cero defectos?

Permitan me una sonrisa irónica, Jeje, no se conocen casos de software que se alegue que sean de Calidad por no tener Defectos sencillamente porque todavía no ha habido un software que no tenga defectos.

4) Que tenga muchísima funcionalidad y features?

Más allá de los casos conocidos como los productos de Office y para que vean que no la tenemos en contra de Microsoft ambos autores de este blog hemos utilizado un par de productos de GIS (Sistemas de Información Geográfica) de una empresa anglosajona que se podrían definir como el paraíso de la acumulación de funcionalidad y features. Uno de ellos se focalizaba en plotear mapas, el otro para hacer carga, procesamiento y consultas en sistemas de información Geográfica.
Cada uno de los productos tenia cientos de features y comandos, muchas veces con funcionalidad superpuesta que creaban una especie de frankestein gordo y pesado, un mamotreto de distintas funcionalidades mezcladas adonde nada se hacia realmente bien o perfomante porque todo era una solución de compromiso para poder hacer muchas cosas que casi nunca se necesitaban.

5) que Sea de bajo Costo y termine dentro de la planificación?

Seguramente son requisitos para el Gerente de un proyecto, el de Marketing o Ventas e incluso los interesados o StakeHolders pero...y los usuarios?

6) Que tenga buena calidad de desarrollo?

Esto justamente es lo que hablamos en el post anterior, y así como creemos profundamente que es un requisito indispensable por el mismo motivo que un edificio sin buenos cimientos se derrumbará, no es suficiente para que todo el producto, el sistema sea de Calidad. Es decir, podemos tener un sistema de una calidad de desarrollo excepcional pero que no sea útil para el o los usuarios en cuestión.

La raíz del problema

Justamente el problema que tiene cada una de las definiciones que intentamos y que han sido intentadas alguna vez, es que la CALIDAD es un término relativo. La calidad que es adecuada para una persona o tipo de persona puede ser totalmente inadecuada para otra.

Jerry Weinberg en su libro "Quality Software Management: System Thinking" habla justamente sobre este tema, y en particular como este concepto de "relatividad" se esconde incluso en
algunas de las definiciones más famosas de Calidad de Software.

Por ejemplo la de Crosby: "Calidad es el cumplimiento y satisfacción de los requerimientos", es decir que un sistema es de calidad si cumple con sus requerimientos.

El tema, o kid de la cuestión y que deberíamos preguntarnos es:
"Requerimientos de Quien o para Quien?", entonces, para ser más precisos deberíamos decir:

"Calidad es el cumplimiento y la satisfacción de los requerimientos de algunas personas"


Para cada persona el mismo producto tendrá distintas "calidades" y de hecho entonces cada sentencia que alguna vez se ha hecho o se hará acerca de la calidad del un sistema es una sentencia acerca de lo que consideran que es la calidad un determinado conjunto de personas.

Por ello, la próxima vez que estés desarrollando software, siempre, siempre preguntate:

"Quien o quienes son las personas detrás del concepto de calidad que están pidiendo para este sistema en particular"

lunes, 28 de marzo de 2011

Optimización de performance

En estas últimas semanas estuve dedicado a la optimización de la perfomance de una aplicación. Siempre es una actividad divertida, aunque muchas veces el esfuerzo invertido es demasiado en comparación con los resultados obtenidos. Por eso, armé esta lista de cosas a tener en cuenta, en base a la experiencia obtenida en esta y en otras batallas.

1. Medir antes de optimizar

Es muy difícil determinar a priori que componentes u operaciones causan que una aplicación no sea perfomante. Las intuiciones acerca de esto son casi siempre erróneas porque se corresponden con algo eminentemente subjetivo como el tiempo: el usuario o el programador recuerda que una operación le llevo "mucho tiempo" en alguna ocasión y piensa que eso es lo que hay que optimizar. Las mejoras de perfomance son también muy difíciles de ver a ojo, ya que pueden ser practicamente impercertibles.

Para evitar tener este problema, tener una métrica tomada en forma automática que nos permita tener una idea de la realidad y evite el andar adivinando. Hay muchas herramientas para escribir tests que simulen usuarios accediendo a nuestra aplicación, aunque a veces se complica su adaptación a una aplicación en particular o tienen licencias caras. En nuestro caso pudimos lograr scripts que simularan miles de usuarios utilizando simplemente Ruby y Mechanize.

2. No sirve optimizar fuera del cuello de botella

El código es siempre optimizable. Si miramos durante el tiempo suficiente cualquier método, se nos va a ocurrir alguna manera de lograr que sea más eficiente (y si no se nos ocurre nada siempre queda la opción de reescribirlo en C :)). El problema es que si optimizamos código que no es el cuello de botella de nuestra aplicación, nuestros usuarios no van a sentir ninguna mejora de perfomance. Si un proceso gasta el 95% de su tiempo de ejecución en una sola tarea, cualquier optimización en el resto del código va a ser impercertible. Nuevamente, es muy importante medir para poder determinar donde se encuentran estos cuellos de botella. Las herramientas más útiles en este sentido son los profilers, que nos permiten saber cuales de nuestros métodos utilizaron más tiempo de ejecución.

3. En vez de realizar micro optimizaciones, buscar maneras de reutilizar objetos ya calculados

En general, no es fácil encontrar optimizaciones importantes en código razonablemente bueno. Salvo casos muy particulares, el algoritmo que intuitivamente primero se nos ocurre es suficientemente bueno. Esto causa que optimizar estos algoritmos es una tarea con esperanzas de recompensas bastante bajas y al mismo tiempo bastante riesgosa. Por eso muchas veces es más conveniente guardar el resultado de un algoritmo para su posterior reutilización que buscar oportunidades de optimización; después de todo, el código que no se ejecuta siempre es el más rápido... Sin embargo, cuando decidimos utilizar estas técnicas, hay que tener en cuenta que estamos ganando velocidad de ejecución a costa de mayor utilización de memoria y que si este uso de memoria sube demasiado el uso de CPU también se va a disparar, por la mayor necesidad de ejecutar el Garbage collector. También hay que tener en cuenta que los resultados que tenemos cacheados pueden volverse obsoletos.

4. Aunque tengamos problemas de perfomance, la calidad del código es más importante que su eficiencia.

Despues de unas semanas enfocados en la perfomance de una aplicación, es fácil que confundamos las prioridades, así que vale la pena remarcar que la calidad interna del código sigue siendo la prioridad número uno. La principal característica del código de mala calidad es que es muy difícil de modificar, lo cual hace que sea peligroso implementar cambios que mejoren la perfomance.

5. Tener métricas reales de uso (o por lo menos una idea)

Muchas partes de nuestra aplicación se van a utilizar raramente o nunca. Otras partes se van a utilizar pero con muy pocos datos. Otras se van a utilizar en forma batch, sin usuarios esperando su resultado. Todas estas áreas tienen algo en común: no tiene sentido optimizarlas. Para saber en donde nos conviene enfocar nuestros esfuerzos, es necesario tener algún tipo de métrica que nos indique que módulos son los que realmente se utilizan.

6. Reglas de la optimización de código

Hacer que nuestra aplicación ande más rápido es algo que en general nos entusiasma como programadores. De todas maneras, siempre hay que tener en cuenta lo que la sabiduría de las generacion anteriores nos dice al respecto:

"Premature optimization is the root of all evil"
 DonaldKnuth
 "Rules of Optimization:

 Rule 1: Don't do it.
 Rule 2 (for experts only): Don't do it yet."

 Michael Jackson (no, no es ese, es otro Michael Jackson)

viernes, 18 de marzo de 2011

Calidad del desarrollo II - Breve Historia

La definición de Qué es la calidad del desarrollo de software ha ido cambiando, como la moda en ropa y peinados, a lo largo del cortísimo tiempo (si lo medimos en eras geológicas) desde que en este planeta comenzamos a escribir programas para indicarle a ese merengue de transistores (antes) y circuitos (después), llamado Computadora u ordenador, como realizar una determinada tarea llamada cómputo.

Ha ido variando, deciamos, un poco como la moda, en tren de determinada corriente, modificada por los distintos paradigmas de programación, y metodologías en boga en cada momento.

70's - Programación Estructurada

Primero tenemos la definición típica de la Programación Estructura, si bien tuvo posteriormente un "aggiornamiento" durante los 80's con la aparición de la Programación Orientada a Objetos. La misma dice que un sistema tiene una buena calidad de software si todos sus módulos tienen una Alta Cohesión funcional y un bajo acoplamiento. Con la aparición de la POO lo que se hizo fue redefinir como interpretar lo de cohesión y acoplamiento no ya en módulos sino en clases de Objetos.

80's - 90' - Las leyes y patterns de POO

Desde la aparición de la POO en el Mainstream (es decir, como paradigma de desarrollo aceptado masivamente) a lo largo de los 80 y 90's se redifinió como obtener una buena calidad de desarrollo a través de un conjunto de leyes, principios y patrones de diseño que especifican que un diseño de un sistema programado con objetos es bueno (la calidad por lo tanto es "alta") si cumplen con estas leyes, principios y utiliza, cuando se debe, estos patrones. Ya hemos hablado aqui de algunas de estas leyes y principios en la-ley-de-demetrio-y-otras-yerbas-oo y en ejemplos-de-la-ley-de-demeter.

2000's - Visión desde TDD Con la aparición de las metodologías ágiles en general y en particular con la práctica de TDD surge una definición muy interesante de que debe cumplir un código para tener buena calidad, a partir de los tests de unidad:

Un sistema tiene buena calidad de desarrollo si el código de todo el sistema (sean Clases o módulo) es el el más simple posible que ofrezca la solución al problema determinado. Y, cuando un código es el más simple posible? Cuando

  1. Corre todos los tests de unidad correctamente.
  2. Expresa cada "idea" del modelo que se necesita expresar (para resolver el problema).
  3. El código modela cada "idea" una y sola una vez.
  4. Tiene el mínimo número de clases y métodos para lograr los puntos anteriores.

Más allá del 2000 y pico - Dos Calidades

En los últimos años, junto en parte a la explosión de aplicaciones web, tanto Kent Beck como Martin Fowler vienen marcando un punto válido (y bastante obvio si uno se para ha pensar) de porque es tan difícil para un equipo de desarrollo hacer entender que la Calidad del desarrollo importa y es fundamental.
Lo que dicen es que los usuarios no entienden la importancia de la Calidad del desarrollo porque hay 2 dimensiones de la calidad, digamos 2 calidades distintas.

La Calidad Interna: Es la calidad del desarrollo propiamente dicha, el como esta construido por dentro, si cumple con la cohesión-acoplamiento, con las leyes de objetos y con la definición de TDD y buena refactorización de código. Es como la conocemos nosotros, la gente de sistemas.
El problema es que esta calidad no es directamente perceptible por los usuarios. Solo ven los efectos. Y por lo tanto, a priori, no les importa.

La calidad Externa: Es la calidad del sistema que puede ser percibida directamente por el usuario. Es cuan agradable y efectivo es el uso del sistema para el usuario, cuan buena es la usabilidad de su interfaz de usuario, de sus reportes, cuan rápido y perfomante responde el sistema ante su uso.

Este concepto bastante obvio, siempre ha existido, desde que los sistemas tuvieron usuarios, pero es interesante notarlo porque ha veces lo hemos pasado por alto o lo olvidamos.

Así, para esta concepción mas completa la calidad de un desarrollo de software es alta si tiene tanto calidad interna como externa.

Calidad Negociable


El punto más interesante aquí, como explica Martin Fowler en este articulo aqui es que la calidad externa de un sistema es algo negociable por tiempo y costo mientras que la calidad interna no.

"Deseas agregar una grilla que muestre a los clientes con fotos, con efecto esfumado y que roten 3D? Perfecto pero eso lleva más tiempo y dinero, si el usuario lo acepta no hay problemas pero mientras tanto, la grilla 2D que tenés (sin fotos) te sirve para comenzar a utilizar el sistema? Fantastico".

No tomen prisioneros


La calidad interna por otro lado no es negociable porque nosotros como programadores tenemos la responsabilidad profesional de preparar el sistema para ser mantenible a lo largo del tiempo y modificable (a los cambios de alcance). De la misma manera si vamos a la metáfora del arquitecto sería lógico que el usuario nos plantee que la construcción que estamos haciendo para que vaya a vivir le demos prioridad a las habitaciones y cocina antes que a la pileta de natación. Pero por otro lado si quieren que vayamos más rápido y eliminemos columnas o cambiemos el material de los cimientos nos negaríamos rotundamente, porque somos profesionales responsables y eso no es sustentable en el tiempo. No es, para cerrar el circulo, mantenible.

Costante universal


Intuitivamente todas sabemos que es la calidad de desarrollo de software y desde este blog hemos machacado una y otra vez con el concepto de que es fundamental toda vez que una buena calidad de desarrollo de sofware permite la màs importantes de las "ilidades" como es la Mantenibilidad, fundamental porque es la actividad que uno mas realiza sobre un sistema. A la vez una buena calidad ayuda tambien a la reusabilidad .
Por último es importante como vimos en el post anterior porque ayuda a aceptar cambios de alcance y de definición del usuario (que como ya explicamos son ineludibles) y permite incorporarlos al sistema de una manera menos costosa y con mucha menos perdida de tiempo que con un sistema de calidad baja.

Por ello, para terminar, como diría Stephen Hawking, la Calidad del desarrollo de software mas que una de las 4 variables del desarrollo debería ser una Constante Universal.

jueves, 10 de marzo de 2011

Calidad del desarrollo I - El Pato de la boda

Volviendo de un periodo de inactividad en este blog a causa de vacaciones varias, algún que otro viaje y temas de trabajo de variada indole vamos a retomar nuestra habitual lucha entre bits, bytes, tuits, posts y lo que toque en suerte.

Hay un tema que siempre ha sido muy caro (por querido, no por el costo, aunque tiene que ver) a mis sentidos y es el tema de la Calidad de un desarrollo de software.

El tema, específicamente para este post es el siguiente:

Cuando comienza un proyecto somos todos buenos, las mejores intenciones son puestas en la mesa, y las buzzwords y palabritas fashion del momento vibran en el aire. Se escucha a programadores, funcionales, testers y lideres decir frases como por ejemplo:

"Vamos a trabajar con OOP bajo arquitectura SOAP y BRMS" "Utilizaremos CEP, BDD, MDD y TDD.", "Aplicaremos los mejores Design Patterns, el GOF, AOP y la madre que me pario."

y así en esas primeras reuniones todo es redondo y bonito, el papel lo soporta todo, así que el diseño de alto nivel cierra y reunidos ante la mesa redonda todos juramos proteger la Calidad del desarrollo cueste lo que cueste, verdad?

Bueno ahi entran a tallar el circulo de presiones de las 4 variables de todo proyecto (de sistemas por lo menos, que es lo que uno ha trajinado bastante):

Como todos sabemos las decisiones y acciones que realizamos durante un proyecto afectan constantemente a estas cuatro variables que están interrelacionadas y uno no puede manejar las cuatro a la vez (y eso de poder definir siquiera dos ya es de por si bastante difícil). Simplificando bastante (y lo que sigue si hilamos fino ni siquiera es totalmente cierto) o bien definimos el costo, alcance y la calidad y eso hace que el tiempo no pueda fijarse y será el tiempo que tome realizar ese alcance con ese costo y calidad. O bien definimos el alcance, tiempo y costo, y la calidad será la calidad que se pueda obtener con ese alcance, tiempo y costo.

Entonces, lo que sucede habitualmente es que un proyecto comienza con un alcance dado, un tiempo mas o menos definido de finalizacion, un costo fijo y determinado hasta los centavos y la promesa de una calidad altísima. Si, por si no se han dado cuenta empezamos casi queriendo violar las leyes de la física y manejar las 4 variables!

A continuación sucede algo conocido como "la realidad". Es decir, el alcance cambia. Siempre. De verdad. Siempre.

O bien el usuario se da cuenta que lo que pidió no es lo que quería, o se da cuenta que le falto pedir funcionalidad im-pres-cin-di-ble, o lo que era un simple linea en un documento termina siendo una funcionalidad clave cuyo desarrollo implica 3 módulos nuevos o bien el negocio o las leyes cambian o lo que sea pero lo cierto es que cambia. De cuando se de cuenta de esto depende en parte de la metodología de desarrollo que se utilice, no quiero entrar en detalle pero digamos simplemente que la tradicional en cascada suele hacer que el usuario se entere cuando ya no puede cambiar nada.

Uno puede tomar ante esta realidad dos caminos. O bien congela el alcance rechazando los cambios o bien permite los cambios. No vamos a discutir aquí que pasa si uno rechaza los cambios obligando al usuario a aceptar que desarrollemos un sistema que no necesita.

Al permitir los cambios sabemos que como el alcance ahora es mayor las otras variables se verán afectadas. El tiempo para terminarlas crecerá , saldrá mas caro terminarlo o..... o la calidad del producto sufrirá.

El costo en general es casi un taboo tocarlo. Implica decisiones políticas. Implica que el gerente del proyecto hable con el cliente o el gerente interesado (el que deberá "pagar") y blanquee la situación para asumir un cambio en el presupuesto. Todo lo cual es....complicado.

El tiempo para hacerlo también es parte de los "Intocables". En reglas generales hay deadline y fechas comprometidas dentro de los proyectos que implican determinadas promesas a clientes o sectores externos, promesas que de no cumplirse pueden traer problemas. En otras casos las fechas sirven como puntos de coordinación con otros eventos (lanzamiento de productos, de campañas de marketing, de instalación y capacitación para el nuevo sistema, etc.) que hacen que sea oneroso o muy impactante su prorroga.

Ni que hablar del costo.

El pato de la boda termina siendo siempre siempre la calidad.

El problema en este caso, material de otro post que publicaremos posteriormente, es que es, para seguir con las metáforas de patos y cazadores, como dispararse en el propio pie.

Cuando uno afecta a la calidad afecta fundamentalmente(el detalle, como dije, para un post próximo) a la velocidad para cambiar el sistema, a su estabilidad y mantenibilidad, es decir afecta en una espiral ascendente al tiempo y al costo.

Es decir que....porque cambio el alcance o nos estamos atrasando, para tratar de cumplir con la fecha y el presupuesto inicial dejamos de lado justamente la Calidad lo cual hace que vayamos MAS LENTO y terminamos no respetando ni el tiempo ni el costo. Y para colmo nos queda un sistema inmantenible!!.

Y ni que hablar que todavía no definimos que entendemos exactamente por calidad de desarrollo! Otra tarea para el próximo post!.





Nota de autor: "Ser el pato de la boda" es una expresión utilizada al menos en Argentina refiriéndose a alguien que carga con las responsabilidad de algún suceso sin ser el culpable y que debe pagar por ello.

martes, 25 de enero de 2011

Vida de Programador I - Como explicar agiles a los Gerentes

El problema es justamente ese: Como explicamos lo que hacemos al Gran-Jefe-Quiero-Que-Cumplan-con-La-Fecha?.

Estas un día tranquilo en tu cubículo, esperando mientras la máquina cachaza que te dieron arranque y levante el IDE superperfomante gratuito que te bajaste por izquierda, cuando recibís la siguiente llamada:

"Juancito, te llama el Gran-Jefe-Quiero-Que-Cumplan-con-La-Fecha, que quiere hablar con vos, pasa a su oficina."

Con una cierta inquietud en tus entrañas te vas para la oficina como quien camina sobre piedras descalzo. Te vas pensando de que vendrá el tema, si tu cv está actualizado en Linkedin o si te sera posible pagar la siguiente cuota del televisor LCD sin trabajo. En síntesis, vida del programador que le dicen.

"Pero Si, hombre, como andas?, pasa pasa, siéntate en esa silla", dice, señalandote una sillita de juguete, bajita, mientras se apoya en el Gran-sillón-De-Cuero-2-metros-de-Alto, para preguntarte:

"Hombre, que te he llamao porque un Gerente amigo, cuando estaba jugando al Golf, me ha hablado de no se que rollo de unas metodologías ágiles, escram(sic) o cosillas por el estilo, no se bien. Creo que hablaba de algo así como focalizarse en la entrega al usuario, en lo que quiere, que el cambio es un rollo normal y no recuerdo pero algo sobre la importancia de las personas por sobre no se que coño."

"Punto numero 1:", pensas, "Este cabron no sabe ni como me llamo". "Punto numero 2: Dios no existe, mierda."

"En sintesis, joder, que me gustaría que me explicaras este follón, porque me ha picao el bichito de la curiosidad, no sea que puedo salir en la gran magasine "MANAGEMENTO" y me estoy perdiendo una oportunidad de la Ostia!!."

"Es definitivo", seguis pensando mientras lo miras con cara de sesudo, "Si, Dios existe pero es un sádico o bien, en la reencarnación anterior debo haber sido muy mala persona....".

Pero bueno... repitiendote pavadas como "en la cancha se ven los pingos" (hmm pero no soy caballo ni galgo)... o "los cobardes no hacen historia" (pero todos murieron de viejo)... te pones a pensar como explicarle al Gran-Jefe-plin plin plin, lo que te pide....

Como explicar que la calidad si importa. Que no hacerlo bien es justamente no llegar a tiempo porque los intereses de la deuda tecnica te comerán vivo como si tu acreedor fuera la mafia misma (bah o algún banco...) .

Piensa piensa piensa...

Del PMI y Waterfall a Scrum

La diferencia fundamental que uno ve al pasar de trabajar de la manera tradicional PMI-Waterfallistica a Scrum es que uno se va chequeando durante el proyecto que esta construyendo lo que el usuario quiere.

El gran problema con la manera "tradicional" es que la forma en que plantea encarar los proyectos es, engañosamente, muy razonable y atractiva: Hagamos un proyecto dividiéndolo en etapas bien marcadas adonde en cada etapa nos aseguramos de hacer bien una y solo una tarea. Hagamoslo en cascada de manera que la actividad de la etapa siguiente se apoye en lo que se hizo en la etapa anterior, como construir un puente, que joder, relevamos, armamos una maqueta, los planos y a construir, todo muy ingenieril, si, si. Pero si hasta parece una receta, un poquito de harina por acá, levadura por allá, 10 minutitos de horno y Voila! la Torta del proyecto esta cocinada, no? No.

Comienzo de un proyecto a-la-tradicional

Es la primera etapa, Gran Relevamiento, el primer paso de la Receta Torta-A-la-Waterfall: Tomémonos todito TOODO el tiempo necesario para entender lo que quiere el usuario, hagamos casos de usos, diagramas de realización, armamos minutas de reunion de todo lo que se hablo en infinidad de reuniones con los usuarios, hagamos prototipos, maquetas, y documentemos en un gran Documento de documentación (valga la redundancia) hasta el más mínimo detalle de lo que el usuario quiere, no sea cosa que después nos pida algo que no mencionó antes. Y si se olvidó de algo...., jah! al banquillo de los acusados!

Tipica reunion de Relevamiento

El funcional, canchero, pregunta:
"Che, A ver, es esta pantalla, en el menu 48, item 256, fijate en el caso de USO de UML2, en Rational: Agregando informacion a la solicitud XRF-3456, te parece que si queres especificar la lista de boxitracios te pongamos un listbox sincronizado con este checkbox o lo hacemos igual que la lista de parafernoles que te mostramos en la maqueta del caso de Uso UJ323 hace 8 días? ".

El usuario nos mira con una sonrisa tímida y balbucea alguna respuesta al azar mientras piensa:
"Merda!, que catzo estará diciendo este tipo por dios?! porque no pueden hablar en castellano?. No voy a decir que "si" ni en pedo, no se a que me estoy comprometiendo."

Despues de eso deberias explicarle al Gran-Jefe-Quiero-Que-Cumplan-con-La-Fecha:

Que ventaja tenemos si usamos Scrum o alguna otra metodología ágil?

El beneficio mas importante de aplicar una metodología ágil en un proyecto es que nos permite instalar dentro del grupo una forma de trabajar en la cual es mucho mas probable que logremos entender y desarrollar el sistema que el usuario realmente necesita. El secreto es simple: Feedback Feedback y mas Feedback.
Feedback constante durante muchas iteraciones para mostrarle una y otra vez lo que entendimos que el usuario pidió y corregir una y otra vez el rumbo en base a su revisión.

Agiles es más que feedback constante y un proceso de mejora iterativa

Claro, el tema es que vamos a pemitir que el usuario en cada iteración nos diga en que difiere lo que hicimos de lo que ahora ve que El necesita. Notar el "ahora", porque es justamente cuando lo ve funcionando que se da cuenta que lo que pidio no es exactamente lo que necesita. O bien, se da cuenta que puede accederlo de alguna manera distinta o entiende lo que le dijimos cuando le deciamos que probablemente la pantalla se vea un poco...saturada de informacion, es decir, confusa.

Y, como vamos a permitir eso; perdón, no solo a permitirlo, como vamos a alentar para que lo hagan, TENEMOS QUE poder cambiar el software, cambiarlo a veces de una manera radical, rapida . Cambiarlo, generalmente, de una forma no prevista en el momento de hacerlo.

Por eso, para que esto sea posible, en un tiempo razonable y que no genere un código fuente inmantenible es que se necesita desarrollar código de calidad.Y para ello se necesitan buenas prácticas de desarrollo.

Cuales? y bueno, por lo menos una malla de seguridad de tests de unidad con un cubrimiento alto del código del proyecto, si es posible hacer TDD, aplicar refactoring constantemente para mantener la calidad y no generar deuda técnica, integración continua, aplicar diseño incremental y evolutivo, técnicas de programación de a pares, Tests de aceptación....etc...

Con tu metabolismo acelerado pensastes todo esto en una fracción de un segundo. Tu jefe, el Gran-Jefe-plin plin plin esta esperando la respuesta, repechado en su Gran-Sillon, te mira desde las alturas y ya se impacienta.

Pensas todo lo que tenes que decirle, pensas en lo difícil que es que lo entienda porque no sabe del tema ni por lejos, de como inventar metáforas simples y futboleras, de lo peligroso que lo malinterprete, sopesas pros y contras, hasta que llegas a la única conclusión lógica posible...

"Pues entonces Juancito? "

"Entonces nada Gran Jefe, son unas metodologias de desarrollo poco serias, chorradas no importantes para un gran Jefe como usted, el camino mas serio e importante es seguir el pinbuk del Gran Libro del Management, PMI, el curso que hizo usted durante 2 años, jefe, ese que le salio lo que yo gano en 5 años. "

"Pero, estas seguro ? mi amigo parecía al tanto de que esto era poco menos que un filón de oro."

"Seguro, Jefe, fijese que tiene nombres raros como Scrum, Extreme Programming, tests de unidad, diseño emergente, metaforas, People over Process" y cosas así, suenan poco serio, no?

En lontananza se escucha el canto de un gallo...

martes, 11 de enero de 2011

Como y porqué de las excepciones

Las excepciones fueron uno de los grandes avances de los lenguajes de programación modernos (y somos concientes de que al llamar modernos a lenguajes como Java o C++ se nos están cayendo varias sotas...).

Antes, cuando programábamos en C, nuestro código tenía esta pinta (ejemplo tomado del brillante "The Pragmatic Programmer" ).


    retcode = OK;
    if (socket.read(name) != OK) {
      retcode = BAD_READ;
    }
    else {
      processName(name);
      if (socket.read(address) != OK) {
        retcode = BAD_READ;
      }
      else {
        processAddress(address);
        if (socket.read(telNo) != OK) {
          retcode = BAD_READ;
        }
        else {
          // etc, etc...
        }
      }
    }
    return retcode;

Mientras que con excepciones podemos hacer


    retcode = OK;
    try {
      socket.read(name);
      process(name);
      socket.read(address);
      processAddress(address);
      socket.read(telNo);
      // etc, etc...
    }
    catch (IOException e) {
      retcode = BAD_READ;
      Logger.log("Error reading individual: " + e.getMessage());
    }
    return retcode;

Con lo cual es claro que las excepciones nos ayudan a escribir mucho mejor código. Sin embargo hay muchas situaciones donde no son la mejor solución y deben ser evitadas. Veamos el siguiente ejemplo

 try {
  f = Float.parse(userInput);
 } catch(MalformedFloat e) {
  f = defaultValue;
 }

En este caso, estamos aprovechando que el metodo parse dispara una excepción cuando le pasamos valores incorrectos para continuar con el procesamiento en el handler de esta excepción. Y estamos usando excepciones para manejar un caso no excepcional: los usuarios suelen equivocarse en el input. El problema es que las excepciones disparan un salto de control bastante parecido a un goto (cuando se produce una excepción se salta del contexto actual hacia otro contexto, probablemente en otra clase y con varias ejecuciones de bloques finally entre medio). El código que depende de excepciones para el manejo de situaciones normales suele tener el mismo tipo de problemas que el código que usa gotos.

Una alternativa sería escribir el mismo código de la siguiente manera:

 if(Float.canParse(userInput)) {
  f = Float.parse(userInput);
 } catch(MalformedFloat e) {
  f = defaultValue;
 }

Para hacer esto dependemos de que la clase Float nos brinde la posibilidad de chequear el input antes de usarlo, lo que nos da un buen consejo para cuando diseñamos nuestras propias clases: siempre ofrecer maneras de verificar que no se deberían producir excepciones.

Por supuesto, si la operación que dispara la excepción es muy costosa o es destructiva, nos veremos forzados a usar la primera alternativa.