Extraordinario evento sobre C++ en Huesca

Microsoft nos propone un espectacular evento sobre C++ en Huesca. Son dos días en los que podremos experimentar las mejoras y espectaculares posibilidades de C++ con utilizando una de nuestras propias aplicaciones.

Si estaís planteandoos migrar una aplicación desde versiones anteriores de C++ a Visual C++ 2005 es una oportunidad única de hacerlo guiados por excelentes profesionales. Sin duda C++ es el lenguaje que más a evolucionado y mejorado con la aparición de Visual Studio 2005 y el más potente de los lenguajes que proporciona Microsoft.

A mi, desgraciadamente, mi agenda no me va a permitir asistir. Cuando lo he visto me he llevado un disgustillo. Es un evento muy goloso, sobre todo siendo MVP en C++. Dos días disfrutando con el lenguaje rey!!! Una pena, los eventos exclusivamente enfocados a C++ no abundan mucho.

Para aquellos que tengaís idea de ir a este evento, os recomiendo hecharle un vistazo a los siguientes articulos de la MSDN Magazine:

C++: Write Faster Code with the Modern Language Features of Visual C++ 2005

C++ Rules: Power Your App with the Programming Model and Compiler Optimizations of Visual C++

Still in Love with C++: Modern Language Features Enhance the Visual C++ .NET Compiler

Pure C++: Hello, C++/CLI

C++ At Work: Managed Code in Visual Studio 2005

On behalf of the Visual C++ Team and Microsoft Spain, you are cordially invited to a Microsoft Visual C++ Accelerator Lab on November 13th and 14th at Huesca, Spain.

In this lab, you will learn about the new security, performance, and productivity benefits of Visual C++ 2005. Experts will be on hand to help you successfully recompile your C++ source code using of the latest versions of the Visual C++ compiler.

If you are interested in attending, please register soon. ¡The seats are limited!

What: Microsoft Visual C++ Accelerator Lab
Where: Aragón Microsoft Tecnology Center: Huesca – España
When: November 13th and 14th
Time: 9 a.m. to 6 p.m.
Limit: 2 guests per company.
Registration: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032302529&Culture=es-ES

What you will accomplish

You will learn about improvements to developer productivity in the Visual Studio 2005 release, ways to make your application more secure, increase performance, mix native and managed code, and upgrade from prior versions of the Visual C++ compiler. You will gain a clear understanding of Microsoft's direction and ongoing commitment to provide the best tools for C++ developers.

We will work side by side with you in utilizing the techniques you have learned as you recompile your own application. Microsoft staff will be available on site to assist you. Our goal is that you walk away with a version of your application compiled with Visual C++ 2005.

Event Highlights

  • Tour of Visual C++ 2005
  • Upgrading from Visual C++ 6.0 and higher
  • C++ / CLI (Common Language Infrastructure) drilldown and language enhancements
  • ANSI C++ conformance
  • MFC (Microsoft Foundation Classes) extension using the .NET Framework
  • Security enhancements
  • Mixing managed and native C++ in the same application
  • Profile Guided Optimization

Who should attend

This event is designed for experienced C++ developers working for organizations with a substantial Visual C++ code base.

Pre-requisites

For the hands-on portion, you should bring your own computer with your application development environment.

Checklist:

  • Laptop with application development environment
  • Install Visual Studio 2005
  • Install source code for your application

Logistics

Venue: Aragón Microsoft Tecnology Center
Dpto. Walqa
Parque Tecnológico Walqa, Carretera de Zaragoza, N-330a, Km 566
22197 Cuarte (Huesca – España)
Directions: http://www.microsoft.com/spain/partner/isv/aragonmtc/localizacion-en.mspx

Number of Seats

24 Seats

P.S. The registration will be First Come First Served basis

We sincerely hope that the content of this lab is of your interest

¿Nos podemos caer de maduros?

Leo en el numero 29 de la excelente revista dotNetMania, un artículo de opinión Antonio Quiros, que no puedo dejar de comentar aquí. En este artículo, el autor defiende que existen ciertos parámetros que nos permiten seleccionar aquellas empresas a las que debemos confiar los proyectos importantes, y que estos parámetros tiene una expresión externa visible: la madurez. En un enfoque muy CMMI, Antonio, propone que aquellas empresas 'más maduras' son las que debemos seleccionar para nuestros proyectos. Antonio solo propone explicitamente que seleccionemos este tipo de empresas cuando nos enfrentamos a grandes proyectos o proyectos importantes. Para mí esto es decir siempre, porque no hay diferencia sustancial en cuanto a técnicas de gesitón entre proyectos pequeño y grandes, por lo menos no a nivel esencial, y para quien nos contrata su proyecto siempre es el más importante.

Si estoy hablando de este artículo, es porque no comparto la visión de la industria del software que transmite. Que nadie me mal interprete, no es que no valore la importancia de las técnicas de estimación, de la gestión de requistos, de la preocupación por la calidad o la gestión de riesgos, pero sin olvidar que son técnicas no valores. Cualquiera que haya asistido a algunos de las decenas de cursos de gestión de proyectos de software que he impartido saben el hincapié que hago en esos aspectos. Eso no quita para que abogue por otro tipo de filosofia de gestión de proyectos y de empresa, que la que defiende el articulo de Antonio Quiros.

En el artículo, Antonio Quiros propone una encuesta ,que nos permite seleccionar la empresa idonea. Siguiendo esta lista no hay duda de que vamos a seleccionar una empresa madura. ¿Pero seleccionaremos la empresa que nos conviene? Puede ser que no, y voy a comentar el por qué.

Atonio Quiros aboga por empresas certificadas, con varias cetificaciones sobre calidad, madurez y demás aspectos. Pero todos hemos sufrido esas certificaciones y sabemos el relativo valor que tienen y como se fuerza que se auditen solo ciertos proyectos o ciertos departamentos. Para el auditor somos el cliente, es dificil que nos suspenda. Ni una sola empresa que se proponga certificarse se queda en el camino y el proceso se suele plantear solo con un fin, obtener la certificación. El fin rara vez es mejorar. Sin duda las certificaciones y las metodologías pesadas son atractivas porque nos eximen de responsabilidad: si el proyecto falla, siempre podemos autoengañarnos con la idea de que lo que fallo es la metodología, no el jefe de proyecto. Además nos permite protegernos del cliente tranfiriendole los costes a el. En lugar de estar haciendo su proyecto innovador, y proporcionarle un clara ventaja competitiva, estamos haciendo su proyecto mediocre pero sin riesgos. El mensaje es: vale esto que te entrego quiza no valga lo que has pagado, pero yo al menos te he entregado algo. Lo mismo se aplica a los desarrolladores, es facil pasar un examen de certificación a base de empollarse respuestas a preguntas y sin tener un profundo conocimiento.

Sin duda asegurar la madurez es un proceso caro. Exige un carga extra de trabajo y burocracia que nuestro cliente tiene que asumir. Sin duda esto reduce los riesgos, son muchos los proyectos que fallan, y evitar los riesgos en en muchas ocasiones vital. Pero existe otra manera mucho más barata de reducir el riesgo y asegurar que un proyecto triunfa: involucrar al cliente.

Otro tema que no comparto es la ilusión de asumir que los requisitos se pueden conocer de antemano. Los requisitos cambian, y luchar contra ese cambio, les cuesta muchos recursos a las empresas 'maduras', que se empeñan en evitarlo. Debemos asumir que esos cambios existen, vivir con ellos y comprender que los cambios surgen porque el cliente gana conocimiento sobre sus necesidades. Y eso debería ser bueno para nosotros, un cliente que descubre sus necesidades y la ve cubiertas por nuestro software, es un cliente satisfecho. Antonio Quiros dice que la principal diferencia de nuestra industria es "la dificil plasmación en lenguaje formal claro de los requisitos funcionales", en mi opión la diferencia es que en nuestra industria, no se pueden plasmar esos requisitos, con un coste razanable, de antemano. Sobre todo usando UML como sistema de Ingeniería de Producto, sea lo que quiera que signifique esta frase, pues no llego a comprender como un lenguaje puede constituir un sistema. Usar UML no es garantia de nada, más bien lo contrario, desde mi punto de vista. Es como proponer que por usar C# o JAVA vamos ha hacer mejor software.

Pensar en garantizar la calidad del software a través de la implantanción de una certificación ISO es como pensar que estudiar literatura te garantiza ser un buen escritor. La norma ISO solo dice que debes establecer un proceso de calidad, pero nada dice sobre como es ese proceso. Puedes certificar en ISO un proceos de calidad del software que sea totalmente ridiculo.

También me parece chocante que cumplir plazos sea algo tan valorado, con ser importante. De nada sirve cumplir plazos, si no entregas valor al cliente. Solo el software que sirve al cliente es medida de avance del desarrollo de software. Entregar en plazo algo que no sirve al cliente, que no cubre sus necesidades y que no se adapta al proceso de descubrimiento de requisitos que surge a lo largo de todo proyecto es algo sin valor. Sin duda yo prefiero gastar los recursos en que el cliente quede satisfecho, no en asegurarme que recibie algo. Entregar algo debería estar asegurado de antemano y no debería costarle dinero al cliente. Yo quiero que el cliente reciba algo que le ayude en como hace su negocio de manera radical, algo imposible si trato de protegerme de el cliente, y no logro su colaboración.

Por todos estos motivos yo propongo una lista alternativa a la que propone Antonio Quiros para evaluar empresas a contratar:

1] ¿Le ha explicado la compañia a contratar que  las estimaciones solo son estimaciones y que estas solo se aproximaran a la realidad según avance el proyecto?
2] ¿Es la compañia a contratar capaz de mostrarle software que otros clientes usan y llevarle a ver como lo usan?
3] ¿Es la compañia a contratar consciente de que los planes fallaran y de que habrá que actuar con agilidad replanificando?
4] ¿Le proporcionará la compañia a contratar software a menudo para que usted pueda juzgar por sí mismo si la calidad es aceptable?
5] ¿Le proporcionará la compañia a contratar software a menudo para que usted pueda juzgar por sí mismo si cubre sus necesidades?
6] ¿Le informará la compañia a contratar de los riesgos para que usted sea quien decida si dedicar recuros a atajarlos o asumirlos?
7] ¿Le proporcionará la compañia a contratar documentación generada directamente desde el código fuente?
8] ¿Es de calidad el código fuente que la compañia a contratar le proporcionará y le puede mostrar el código de otros proyectos?
9] ¿Exigirá la compañia a contratar que usted entienda los requisitos iniciales y se los presentará en un lenguaje natural para usted?
10] ¿Comprende la compañia a contratar que solo conocerá sus necesidades cuando el proyecto vaya avanzando?
11] ¿Me proporcionará la compañia a contratar software ejecutable con regularidad en el que usted pueda basar el proceso de descubrimiento de sus necesidades?
12] ¿Me proporcionará la compañia a contratar software ejecutable con regularidad que me permita ir amortizando mi inversión durante la vida del proyecto?
13] ¿Son los profesionales de la compañia a contratar gente reconocida y respetada en la comunidad de desarrolladores y técnicos?
14] ¿Van a divertise los desarrolladores de la compañia mientras desarrollan mi software?
15] ¿Me garantiza la compañia a contratar que los profesionales que van a llevar a cabo el proyecto son de primera línea y están vinculados a ella?
16] ¿Cuenta la empresa a contratar con desarrolladores que escriben código que prueba su código?
17] ¿Cuenta la empresa a contratar con especilistas en calidad del software integrados en el equipo de desarrollo?

Evidentemente habrá clientes que se sientan más comodos con la lista del Antonio Quiros, pero, hay que tener en cuenta que esa lista no nos separá mucho del enfoque que nos ha llevado a un altisimo porcentaje de proyectos fallidos en los últimos años y que ignorá todos los avances realizados en el campo de la gestión de proyectos de software en los 15 últimos años. Ya he abogado con anterioridad por la elección de los clientes. Y además he visto despues que no soy el único.

En cierto modo, la lista de Antonio Quiros, a mi modo de ver, es seguir tropezando en la misma piedra: poner el proceso por encima de clientes y desarrolladores.

No es la primera vez que abordo estos temas en mi blog, si te interesá lo aquí comentado te sugiero que leas: "No les vamos a volver a engañar", que trata temás similares.

Antonio Quiros, nos comenta que va a ir desgranando sus ideas en proximos números de la revista. Yo no creo que pueda resistir la tentación de ir comentando en paralelo mi punto de vista.

¡MSDN tiene un WIKI!

Ayer de casuidad descubrí que MSDN tiene un Wiki. Para aquellos que no sepan que es un Wiki, decir que según Wikipedia es: "es una forma de sitio web en donde se acepta que usuarios creen, editen, borren o modifiquen el contenido de una página web, de una forma interactiva, fácil y rápida. Dichas facilidades hacen de una wiki una herramienta efectiva para la escritura colaborativa."

Pues bien, lo que permite este Wiki de MSDN es en esencia que podamos añadir nuestras propias contribuiciones a la documentación de MSDN. Así ,si encontramos el típico parámetro que la documentación no explica con suficiente claridad, pues añadimos una entrada contando que problemas surgieron y como los solucionamos, de manera, que el siguiente usuario no se tenga que dar de bruces, toda una tarde, contra el dichoso parámetro. O mejor aún podemos añadir un ejemplo de código para que todo quede claro.

Aún se encuentra un poco en pañales, normal pues está en base beta, espero que no pase como con los productos de google que se pasan 3 años en beta. Me parece una excelente forma de hacer comunidad y de mejorar la documentación. Tendremos que ver como evoluciona.

Revisiones de código con Team Foundation Server

Por su capacidad para detectar y corregir defectos de manera temprana, las revisiones de código son tan importantes como el testeo para controlar los costes y los plazos. Tambien influye positivamente en la calidad del código fuente. Ya he hablado con anterioridad, sobre como cada vez cobra más importancia escribir código de calidad y como incluso hay libros sobre el retorno de la inversión realizada en escribir buen código.

Un estudio del Instituto de Ingeniería de la NASA descubrio que las revisiones de código detectan aproximadamente el doble de defectos por hora que las pruebas, lo que sugiere que un enfoque adecuado para acortar plazos es combinar pruebas con revisiones de código.

Adicionalmente a su impacto en la mejora de la calidad, las revisiones de código sirven como medio de transmisión del conocimiento. Los desarrolladores experimentados pueden solucionar problemas en el código de los inexpertos, los desarrolladores inexpertos aprenden del código de los experimentados. Además sirve para compartir nuevas técnicas aprendidas por los desarrolladores.

El proceso a la hora de realizar revisiones de código incluye:
Notificar y distribuir el nuevo código: el autor del código notifica a los encargados de la revisión que éste ya está disponible.
Realizar la revisión: Los encargados de la revisión, preferiblemente ayudados por un checklist de errores habituales en el pasado, revisan el artefacto.
Evaluar los resultaldos de la revisión: El autor y los encargados de la revisión se reúnen y examinan el resultado de la revisión.
Analizar los resultados de la revisión: Capturar información sobre la cantidad de material revisado, el número y cantidad de defectos detectados, el tiempo utilizado en la reunión de revisión y si el producto pasó o falló la revisión.
Seguimiento: Asegurar que el autor incial realiza los cambios necesarios detectados en la revisión.

Desde el punto de vista de la gestión del proyecto es preciso tener en cuenta que hemos de:
Comenzar en fases tempranas del proyecto las revisiones.
Mantener las revisiones técnicas centradas en la detección de defectos.
Mantener las revisiones técnicas técnicas.
Mantener información sobre qué material ha sido revisado.
Documentar los defectos encontrados durante las revisiones.
Verificar que los defectos encontrados son corregidos.

Realizar estas actividades, sin el apoyo de una herramienta, puede añadir una carga buracrática al proyecto que mina la efectividad de esta técnica. Team Foundation Server no nos ayuda, tal y como sale de la caja, a la hora de realizar revisiones de código.

La buena noticia es que gracias a las excelentes características de extensibilidad de Team Foundatio Server ya al esfuerzoa de algunos desarrolloadores existe un proyecto en CodePlex, del que además podemos ver el código fuente (un excelente ejemplo de implementación de póliticas para Team Foundation Server), cuyo proposito es dotar a Team Foundation Server de las capacidades necesarias para ayudarnos en las revisiones código. Este proyecto se llama TFS Code Review Workflow y proporciona una combinación de un elemento de trabajo (Work Item) para revisiones de código y una política (Check-in Policy) de revisión de código. La pólitica impide que podamos hacer checkín de un código fuente si no tiene asociada un elemento de trabajo de revisión de código y este está aprovado. Solo los usuarios del grupo {Project}Code Reviewers pueden aprobar reviones de código.

Aun se hechan en falta algunas características y en especial el tener algún informe, pero parece que van a trabajar en ello.

Antes de usar este complemento para Team Foundation Server quiza os interese leer Instrucciones para realizar revisiones de diseño y de código en la MSDN, sin duda un documento interesante.

La calidad del software y el código fuente

Siempre he sostenido que la calidad del software empieza por la calidad del código fuente. Basta observar unas cuantas líneas de código de un proyecto, de unos cuanto archivos de código elegidos al azar para saber mucho sobre la calidad del proyecto en genera. Es impensable que con código de mala calidad se pueda construir buen software. Me ha sorprendido ver en Port 25, que Microsoft tiene gente investigando sobre la relación que existe entre la calidad del software y la calidad del código fuente y sobre la importancia del código fuente de calidad.

Hay dos interesante videos en los que se trata el tema:

En el primero, Khaled El Eman, de la Universidad de Otawa, habla sobre el retorno de la inversión del código fuente de calidad. Es curioso como se puede llegar a cuantificar en unidades monetarias la calidad del código en los proyectos. Además este autor tiene un libro que parece interesante sobre el tema del video The ROI from Software Quality y el tema que trataba en mi post anterior sobre como para hacer software en tiempo y coste es necesario hacerlo con calidad.

En el segundo, Brandan Murphy, es intrevistado sobre su investiación sobre la calidad del software.

Una pena que ambos estén en inglés, porque son dos documentos interesantisimos. Mi nivel de inglés no da para una transcripción pero quizá alguien se anime…

Otro documento muy interesante, una vez convencidos del valor de escribir código de calidad, es Escribir código de calidad, que podeís leer en MSDN en español.

Aniversario del primer ‘bug’

Hoy nueve de septiembre se cumple el aniversario del primer error informático, que fue causado por un insecto, que se colo dentro de los circuitos de uno de los primeros computadores. Bug es insecto en inglés y de ahí en adelante se popularizo el termino para referirse a los errores.

Interesante el hecho de que se conserve ese primer error. Triste final para una vida de polilla, acabar pasando a la historia pegado con un trozo de celo a un cuaderno de bitacora de un servidor.

Disponibles las Team Foundation Power Toys

Team Foundation Power Toys es una colección de herramientas de productividad para Team Foundation Server. Nacidades de la experiencia práctica usando Team Fundation Server, son una conjunto de herramientas de línea de comando de herramientas integradas en Visual Studio que proporcionan posibilidades añadidas y facilidades a los usuarios del control de versiones y de seguimiento de elmentos de trabajo.

No les vamos a volver a engañar

Siempre que tengo el placer de reunirme con un grupo de colegas, con ocasión de alguna charla, curso o reunión del tipo que sea, surge la misma queja: a los informáticos no nos respetan, con todo lo que hacemos por el mundo y nadie valora nuestro trabajo. Sin duda es un sentimiento natural. Cualquier técnico de similar capacitación y conocimientos está mejor pagado que un informático. Pero es un sentimiento que se palpa, los clientes no se fian de la industria informática. Y lo peor que tienen toda la razón. Repasemos que les hemos ofrecido en los ultimos años, en los años de la tan traida y llevada ‘burbuja’. Les prometimos un motón de cosas, B2B que facilitarían su capacidad para hacer negocios, B2C que les proporcionaría una cantidad de ventas fabulosas con solo comprar un dominio y desarrollar una web, ERP milagrosos, CRM que harían felices a sus clientes… el oro y el moro. ¿Y en la mayoría de los casos que han recibido? Más problemas que soluciones, dependencia de grandes ‘consultoras’ que en muchos casos solo han sido capaces de facturar cifras astronómicas por poner becarios vestidos de consultores en las oficinas del cliente.


Rara vez hemos sido sinceros con el cliente, exigiendole que se involucre en los proyectos, dejandole claro que es una parte vital de los mismos y que solo con su completa implicación los proyectos van a triunfar. El motivo es claro, esto se factura mal por horas. No sirve enviar a un becario ha hacer un trabajo que exige mucho más contacto con el cliente, mucha más capacidad de colaboración, mucha más creatividad y mucha más pericia técnica.


Pero esto está cambiando, cada vez más empresas están desconfiando de las ‘grandes consultoras’, de los proyectos ‘llave en mano’ que lo único que aportan al final del mismo es eso una llave, no una solución a los problemas de negocio que el proyecto debia solucionar. Parece que, al menos, a algunos no les vamos a volver a engañar (hablo como conjunto de industria en genera, no dudo que hay excelentes profesionales y excelentes empresas). Al fin y al cabo, el error siempre ha sido el mismo, el cliente solo se limito a aceptar una oferta. No colaboró en el proyecto siendo una parte activa del mismo. Ese ha sido el principal error de nuestra industria, pretender que podiamos actuar sin que el cliente nos guiase constantemente en cual es la solución que necesita. Solo el cliente puede llegar a saber lo que soluciona sus necesasidades, basandose en su conocimiento del negocio y los puntos a mejorar y nuestro conocimiento de como plantear soluciones técnicas informáticas a sus problemas.


Aquí es donde empresas pequeñas, ágiles, con excelentes profesionales, que son parte activa de la comunidad, que realizan su trabajo con autentica pasión y que solo son capaces de llevar adelante los proyectos desde el profundo conocimiento técnico y organizativo de lo que tienen entre manos, promoviendo en todo momento la participación del cliente en el proyecto, tienen un excelente campo de maniobra. Los clientes ya saben lo que han obtenido del enfoque ‘tradicional’ de desarrollar proyectos. Y los profesionales tambien. Sobresfuerzos innumanos, poca diversión en el trabajo, descredito y deshilusión. Es el momento de que las consultoras den paso a otro tipo de empresa.


Sin duda esto tambien exige otro tipo de cliente, que realmente quiera comprometerse en obtener valor de los proyectos y que sea capaz de implicarse en los mismos, que comprenda que está en su mano gran parte del existo del proyecto. Otra condición necesaría es que el cliente confie en quien contraté, pero esto es algo que despues de años de fracasos (la gran mayoría de los proyectos informáticos fracasa) nos lo tenemos que ganar a pulso. En cierto modo estamos en la situación de la pescadilla que se muerde la cola. Los clientes no confian en quien contratan, y por lo tanto dificilmente son capaces de establecer la confianza necesaria para poder colaborar a fondo en los proyectos, anulando uno de los principales factores que llevan al exito de los proyectos, la participación del cliente. ¿Entonces qué solución puede funcionar? Una dolorosa: tenemos que seleccionar al cliente, ser conscientes de que no interesan aquellos clientes que no sean capaces de compartir la necesidad de dar un giro a la forma de actuar de ambas partes hasta ahora.


Claramente a cualquier gerente que este leyendo esto, le están dando vuelta los ojos en la orbitas, cualquiera menos Pablo Pelaez, gerente de Plain Concepts, espero ;). Pero tiene mucha lógica lo que escribo. Les propongo un ejercicio: señores gerentes piensen en los proyectos que han hecho en los que sabian positivamente que el cliente no iba a colaborar, o que sus técnicos no estaban capacitados, o que el presupuesto o la planificación no era realista, o cualquier otro proyecto de esos que nacen dañados desde su origen por el motivo que sea. Ahora piensen en lo que obtubieron, un cliente cabreado, probablemente algún impagado, una gran cantidad de bajas entre sus trabajadores, etc… y sí, ciertamente, volumen de facturación a corto plazo. Ahora piensen en que hubiese pasado si esa energia, recursos, y empeño se ubiesen puesto al servicio de un proyecto de los que han ido bien, fijense en lo que se obtiene cada vez que un proyecto va realmente bien además de una facturación a corto plazo… ¿Seguro que no mereze la pena ‘elegir a los clientes’?


Lo se, lo se, es raro que nos encontremos en la situación de poder elegir a nuestros clientes. Pero lo que siempre podemos hacer es intentar formar a nuestros clientes, plantearles cual es nuestra manera de trabajar, explicarles que es lo que obtendran y por que no queremos seguir haciendo las cosas como ellos están acostumbrados. Algunos, quizás, acepten esta nueva manera de trabajar. Con los que no acepten, siempre podemos seguir tropezando en la misma piedra, que remedio, pero al menos esta vez habremos sido sinceros.