101 formas de saber que tu proyecto está condenado al fracaso

HundimientoMe he vuelto a encontrar con el divertido post 101 Ways To Know Your Software Project Is Doomed, donde se enumeran 101 pistas que te ayudarán a saber si tu proyecto está condenado a fracasar estrepitosamente. Tras contactar con Max Pool, el propietario del blog Codesqueeze, me ha permitido muy amablemente publicar en www.variablenotfound.com una traducción de su post completo.

  1. La dirección ha cambiado el nombre del «procedimiento en cascada» por «cascada ágil».
  2. Se han empezado a contratar consultores para poder echarles las culpas de todo.
  3. El servidor de integración continua retorna el error «Que te jodan. Me largo».
  4. Habéis implementado vuestro propio framework en Ruby que usa archivos de configuración XML.
  5. El miembro del equipo más mayor se refiere a Martin Fowler como «ese gamberro engreído».
  6. Vuestro sistema de control de código fuente consiste en una serie de carpetas en un disco compartido en red.
  7. El tiempo asignado para QA es destinado a preguntarse el por qué de ese desastre.
  8. Todos los requisitos están escritos en una servilleta de papel.
  9. Empiezas a considerar un cambio de empleo para no tener que mantener la aplicación que estás desarrollando.
  10. El responsable de desarrollo web piensa que la X de XHTML viene de «eXtremo».
  11. Las reuniones de todas las iteraciones comienzan por un «¿prefieres las buenas o las malas noticias?».
  12. El equipo todavía considera que su nivel de CMM es una mierda.
  13. El progreso se mide por el número de errores corregidos, y no por funcionalidades o características finalizadas.
  14. La integración continua está haciendo que los empleados nuevos lean el manual del empleado.
  15. Eres amigo del portero.
  16. Al SCRUM master no le importa lo que hicisteis ayer, ni lo que haréis hoy.
  17. Cada hito acaba en un sprint mortal.
  18. Vuestro mejor desarrollador lo único que tiene es su expediente académico brillante.
  19. No entendéis los acrónimos DRY, YAGNI o KISS, pero sí WTF, PHB o FUBAR.
  20. El jefe podría ser sustituido por un script de redirección de emails.
  21. La única certificación de vuestros procesos de construcción de software es la ISO 9001/2000.
  22. El jefe piensa que «métrica» es un tipo de bebida proteínica.
  23. Todos los errores son priorizados como críticos.
  24. Todas las funcionalidades son priorizadas como triviales.
  25. Las estimaciones económicas del proyecto mágicamente coinciden con el presupuesto disponible para el mismo.
  26. Los desarrolladores usan la excusa del código autodocumentado para justificar la ausencia de comentarios.
  27. Vuestro patrón favorito es el god object.
  28. Todavía pensáis que compilar es una forma de testear.
  29. Los desarrolladores todavía utilizan Notepad como entorno de desarrollo.
  30. El gestor del proyecto pasa 7 horas a la semana pidiendo informes de progreso (basado en hechos reales).
  31. No tenéis máquina propia, y no estáis programando por parejas.
  32. Norma del equipo: no hay reuniones hasta las 10:00am, puesto que ayer estuvimos aquí hasta las 2:00am.
  33. En el equipo se piensa que los ORM son una moda.
  34. El equipo piensa que la transición desde VB6 a VB.NET será sencilla.
  35. El gestor piensa que MS Project es la mejor herramienta de gestión de proyectos del mercado.
  36. Tu esposa sólo consigue verte en una webcam.
  37. Ninguno de test unitarios tienen aserciones (asserts).
  38. Vuestro editor de páginas favorito es FrontPage.
  39. Se discute encendidamente sobre si la llave «{» debe escribirse en una nueva línea, pero se es impacial ante el uso de patrones como MVC.
  40. El lema de la compañía es «haz más con menos».
  41. La frase «funciona en mi máquina» se escucha más de una vez al día.
  42. La última conferencia a la que asistió el equipo de desarrollo .NET fue la Apple Worldwide Developers Conference 2000.
  43. Los gestores insiten en registrar toda la actividad, pero nunca usan esa información para tomar decisiones.
  44. Toda la depuración se hace en el servidor en producción.
  45. El jefe no sabe cómo comprobar el email.
  46. El jefe piensa que ser compatible SOX significa no trabajar las noches en las que hay béisbol.
  47. La empresa contrata al senador Ted Stevens para la charla de inicio del proyecto.
  48. El último libro que leíste fue la Biblia de Visual Interdev 6.
  49. El presupuesto general se confunde con tu gasto semanal en Mountain Dew.
  50. El jefe se pasa la hora de la comida llorando en el coche (otro hecho real).
  51. El responsable de desarrollo web define Ajax como un producto de limpieza.

(Seguir leyendo en variablenotfound.com…)

Programadores con producción neta negativa (NNPP)

Borrar... borrar...Cuando me topé por primera vez con el término NNPP (siglas de «Net Negative Producing Programmer») no puedo negar que me hizo cierta gracia. Cuanto menos, resultaba curioso pensar que podían existir desarrolladores cuyo saldo en las aportaciones a un proyecto resultara negativo, o lo que es lo mismo, que el valor de su producción fuera superado por el coste de los errores y defectos que introducían en las aplicaciones. Y con el término «desarrolladores» no me refiero exclusivamente a programadores; el concepto es válido para analistas, arquitectos, testers, o cualquier otro rol relacionado con la construcción de software.

Aunque seguro que todos hemos trabajado con profesionales que consideramos desastrosos poco habilidosos en la ejecución de sus tareas, probablemente no hayamos reflexionado lo suficiente sobre el impacto que tiene esto en un proyecto, y el coste final que clientes, nuestra empresa, o nosotros mismos tenemos que asumir en muchos casos. Es en este momento cuanto la existencia de NNPPs deja de tener gracia.

Y eso mismo debió pensar G. Gordon Schulmeyer cuando escribió, a principio de los 90, el paper «The Net Negative Producing Programmer» para la publicación American Programmer (hoy en día Cutter IT Journal), en el que se describía detalladamente qué son los NNPPs, cómo podemos reconocerlos, los motivos de su existencia, y los posibles remedios a aplicar cuando se detectan en un equipo de trabajo.

Según se manifiesta en este documento, los NNPP no son casos extremos. De hecho, en un equipo de diez desarrolladores pueden existir desde uno hasta tres NNPP, lo cual no es ninguna tontería: entre el 10 y el 30% del equipo de trabajo podría estar contribuyendo de forma negativa al éxito del proyecto. En otras palabras, en lugar de desarrollar estarían desdesarrollando, si me permite el amigo Andrés Panitsch que le tome prestado brevemente el nombre de su genial blog.

Aunque pueda parecer lo contrario, la detección objetiva de los programadores con producción neta negativa no es sencilla. Schulmeyer propone la utilización de un modelo de comportamiento donde se evalúen, al menos, las habilidades para:

  • escribir un programa
  • encontrar y depurar errores
  • ampliar un software para adaptarlo a nuevas necesidades
  • adquirir nuevos conocimientos técnicos
  • comprender un determinado problema

Salvo el último punto, de ámbito más abstracto, existen métricas que ayudan a determinar hacia dónde se inclina la balanza cuando comparamos la productividad de un desarrollador con su ratio de introducción de defectos en el software. Sin embargo, además de los aspectos técnicos, existen impedimentos éticos, y a veces incluso legales, que impedirían la obtención de conclusiones directas a partir de registros de actividad.

Pero probablemente, para poder detectar y evitar la aparición o proliferación de NNPPs en las organizaciones es importante conocer las causas de su existencia. Un estudio citado en el artículo revela causas como la insatisfacción en el trabajo, identificación e implicación nulas con el proyecto, percepción de escasa relación entre profesionalidad y recompensa, y falta de profesionalidad. Es obvio que, transcurridos quince años, siguen siendo válidas hoy en día; y curioso que muchas de ellas sean más atribuibles a la compañía y sus gestores que a los propios profesionales sospechosos de producir en negativo, normalmente por utilizar políticas restrictivas, estresantes, opacas y poco motivadoras para su personal.

La solución para estas situaciones pasa, en primer lugar, por realizar un análisis introspectivo de las condiciones de la organización. Mejorar la comunicación y el establecimiento de objetivos claros y comunes para un equipo de trabajo, por ejemplo, es una medida que puede mejorar bastante la implicación en un proyecto; o la recompensa -no necesariamente económica- por la consecución de objetivos puede incrementar la motivación y autoestima del grupo, y redundar positivamente en la producción.

Respecto al desarrollador, salvo en casos donde existen problemas estructurales graves como la falta total de vocación o capacidad, existen diversas vías para reconducir la situación.

TerapiaUna de ellas es mediante la comunicación entre las partes, algo así como organizar sesiones de terapia, reuniones donde la empresa pueda exponer al trabajador los hechos objetivos y los resultados de su comportamiento, y escuchar atentamente las motivaciones y argumentos de éste.

A veces, la producción negativa es un simple reflejo de actitudes desorganizadas, procrastinación, socialización excesiva, no finalización de tareas, estrés constante, falta de información, y otras muchas. Estas sesiones pueden servir para dar con las causas y acabar con la baja productividad de forma rápida.

Otra posibilidad para solucionar los problemas de productividad es la reasignación, el cambio hacia tareas más acordes con las habilidades y puntos fuertes de la persona. Por ejemplo, un NNPP dedicado habitualmente a la codificación podría convertirse en un buen verificador, o documentador, haciendo que sus aportaciones al proyecto pasaran a ser de signo positivo.

El último recurso es la destitución, que debería aplicarse únicamente una vez agotadas alternativas, digamos «menos violentas», como las citadas anteriormente. Lo normal es que un aviso lo suficientemente claro baste para despertar a cualquiera de su letargo, y no sea necesario llegar a mayores.

En cualquier caso, no cabe ninguna duda es del alto coste de los programadores con producción negativa neta. Un retraso en un proyecto o el lanzamiento de productos defectuosos puede tener un impacto terrible en la imagen de una empresa, y en el peor de los casos, hasta puede ocasionar desastres de magnitudes considerables. Y por no hablar de consecuencias internas, como la ruptura de la cohesión en equipos de trabajo, disminución global de productividad, aumento de desconfianza del grupo, incremento de costes, y un largo etcétera.

Semanas atrás Jay Field hablaba también de efectos nefastos para la propia industria del desarrollo de software, porque estos profesionales podían llegar a frenar el avance y la introducción de nuevas tecnologías, e incluso del terrible daño que se puede causar a las próximas generaciones de desarrolladores que durante su proceso de formación y adquisición de experiencia sean puestos a cargo de NNPPs.

Lamentablemente, los desarrolladores con producción neta negativa están aquí para quedarse. Tendrán hueco siempre que existan empresas donde no se cuiden detalles como el ambiente de trabajo, la transparencia, la comunicación, no se fomente la implicación y motivación del trabajador, o cuyos criterios de selección de personal consistan en elegir siempre a los profesionales de menor coste.

Enlaces:

 

Juega con las API Ajax de Google

Ajax API PlaygroundUnos días atrás, Ben Lisbakken descubría en el Blog de Google Code el proyecto al que había dedicado el famoso (¿y difunto?) 20% de la jornada laboral en esta compañía: AJAX APIs Playground.

Se trata de un sitio web interactivo en el que se encuentran un total de 170 ejemplos de uso de las siguientes API de Google:

  • API de visualización, que permite a los desarrolladores acceder a datos estructurados y mostrarlos en una gran variedad de formatos, como tablas o gráficos estadísticos.
  • API Ajax para búsquedas, que facilita la incorporación de capacidades de búsqueda de cualquier tipo (páginas, direcciones, multimedia, etc.) en sitios web utilizando javascript.
  • API Ajax de idioma, que nos permite acceder mediante javascript a las herramientas de detección de idioma, traducción y transliteración de Google.
  • API de datos de Blogger, que permite el acceso con Ajax a información sobre blogs, posts y comentarios de esta plataforma de publicación.
  • API de bibliotecas Ajax, la red de distribución de librerías estándar como jQuery, jQuery UI, Prototype, script.aculo.us, MooTools o Dojo.
  • API de Google Maps, con el que podremos integrar Google Maps en nuestras webs y utilizar los servicios de localización y posicionamiento que nos ofrece.
  • API de Google Earth, el cual nos facilita la inclusión del sistema Google Earth en webs, así como la interacción con ellos vía javascript.
  • API Ajax para feeds, un conjunto de funciones que nos permiten obtener feeds de otras páginas sin necesidad de crear proxies de servidor.
  • API de Google Calendar, el interfaz a través del cual podemos crear aplicaciones totalmente integradas con Google Calendar.

Pero, al menos para mí, lo mejor viene ahora: dispone de un editor de código fuente en el que podemos modificar dichos ejemplos, ejecutarlos sobre la marcha e incluso guardar o exportar los cambios que realicemos, por lo que resulta de lo más didáctico y efectivo para hacernos con el manejo de estas potentes herramientas.

Enlace: Ajax API Playground.
Publicado en: www.variablenotfound.com.

Directivas personalizadas en páginas y controles ASP.NET

Qué divertido es esto. Hoy he descubierto una nueva característica que se presentó con ASP.NET 2.0, hace ya algunos añitos: la posibilidad de crear nuestros propios atributos en las directivas de página y controles, es decir, utilizar las líneas @Page y @Control que suelen encabezar nuestros archivos .Master, .aspx y .ascx para asignar valores a propiedades de nuestras clases, como en el siguiente ejemplo:

<%@ Page Language="C#" MasterPageFile="~/Site1.Master" 
AutoEventWireup="true"
CodeBehind="Noticias.aspx.cs"
Inherits="MiPortal.Noticias"
Title="Noticias"
CodigoSeguridad="CD001"
%>

 
Para conseguirlo, basta con que la página o control herede de una clase que incluya propiedades públicas con el mismo nombre de el atributo que queremos usar. Bueno, en realidad, por cortesía de la herencia, la propiedad podría estar definida en cualquiera de sus tipos antecesores. Gracias a ello, podemos establecer mecanismos de control fuertes para asegurar la presencia de estos atributos en las directivas de página, por ejemplo:


public class MyBasePage: System.Web.UI.Page
{
private string codigoSeguridad;
public string CodigoSeguridad
{
get { return codigoSeguridad; }
set { codigoSeguridad = value; }
}

protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
if (string.IsNullOrEmpty(this.CodigoSeguridad))
throw new ArgumentException("CodigoSeguridad no definido");
}
}

 
Si ahora hacemos que todas nuestras páginas hereden de esta clase sustituyendo a la Page estándar, estaremos forzando a que se defina el atributo CodigoSeguridad en las directivas de todos los aspx (lo mismo es aplicable). Para ello, en el archivo CodeBehind(.cs ó .vb) de las páginas deberíamos sustituir la definición por defecto por algo parecido a


public partial class Noticias: MyPage
{
...

 
Como curiosidad, la propiedad se establece antes del evento PreInit, por lo que a partir de este momento del ciclo de vida de la página, podemos usar su contenido de forma segura. Además, admite cualquier tipo de dato que el sistema sea capaz de convertir desde un string; podéis probar, por ejemplo, a crear una propiedad de tipo Color o IPAddress y la plataforma realizará la conversión de forma automática. Eso sí, para usar tipos valor (int, bool…) será conveniente hacer uso de los nullables para poder recoger de forma apropiada la ausencia de la asignación del atributo, preguntando por HasValue(), así:


private bool? mostrarBanner;
public bool? MostrarBanner
{
get { return mostrarBanner; }
set { mostrarBanner= value; }
}
protected override void OnPreInit(EventArgs e)
{
base.OnPreInit(e);
if (!mostrarBanner.HasValue)
throw new ArgumentException
("MostrarBanner no definido");
}

 
A nivel de diseño estos atributos no aparecerán como opciones disponibles, según intellisense, al teclear la directiva @Page; además, si incluís un atributo personalizado de este tipo, el diseñador de Visual Studio 2008 generará un aviso indicando que no es válido; la versión 2005 os mostrará un error, pero podéis ignorarlos tranquilamente en ambos casos:

Validación (ASP.Net): ‘CodigoSeguridad’ no es un atributo válido de elemento ‘Page’

Y para finalizar, todo lo dicho es válido para las directivas @Control de los controles de usuario, salvo en lo referente al evento PreInit, pero podríamos usar Init en su lugar sin muchas contraindicaciones.

Publicado en: http://www.variablenotfound.com/.