Como fracasar con éxito

Recuerdo que llevábamos varios meses encerrados en una de las habitaciones donde vivía con un par de amigos, con la intención de desarrollar software de gestión, apoyados por una pequeña empresa que quería comercializar el producto, ninguno de nosotros cobraba sueldo alguno y manteníamos un estricto horario, similar al de cualquier otra empresa, teníamos el sueño de que algún día podríamos ganar lo suficiente como para establecer una empresa que nos permitiera vivir cómodamente, el trabajo se hacía cada día más duro, pues, además de no contar con ningún incentivo, a final de cada mes, debía asumir algunos gastos derivados de nuestro trabajo, teléfono, gasolina, luz, etc.. La empresa interesada en el producto, nos surtía de material y un poco de equipamiento, algún router para la red, material ofimático y otras cosas. Al cabo de casi un año de trabajo, uno de los compañeros se fue a realizar el servicio militar y nos quedamos solo dos, encontramos la posibilidad de alquilar un local, para nosotros era prácticamente impensable, ya que no disponíamos de ningún ingreso, pero el alquiler era muy bajo y buscábamos la independencia de un lugar para trabajar más concentrados, el local era simplemente una habitación sin ventanas de unos 12 metros cuadrados ubicado en la parte baja de un edificio, decidimos arriesgarnos y sacar la licencia fiscal para poder vender software y equipamiento informático, pensamos que con que lográsemos vender dos o tres equipos al mes y algún programa, podríamos pagar el alquiler y tendríamos lo suficiente como para poder continuar con lo que verdaderamente nos gustaba, desarrollar software, fue curioso como, primero a través de un amigo nos compraron un equipo, luego otro y otro. En poco tiempo las ventas fueron incrementándose, aunque seguíamos sin un nivel de beneficios aceptable, ni siquiera sacábamos lo suficiente para asumir un sueldo. Aun con estos problemas y debido a la ilusión que teníamos por nuestra empresa, decidimos arriesgarnos y alquilar un local más grande de cara al público, solicitamos un préstamo avalados por nuestros padres y comenzamos nuestra primera aventura empresarial.

Lógicamente los gastos se dispararon, tuvimos que contratar a alguien que estuviera permanentemente en la oficina y asumir diversos impuestos y costes derivados de la actividad, acondicionamiento del local, luz, teléfono, etc., así que empezamos a salir a la calle en busca de empresas que nos permitiesen aumentar nuestros ingresos, el camino fue muy duro, establecer una simple entrevista era muy complicado ya que normalmente preferían empresas conocidas o consultoras con mayor experiencia, la mayor parte de los empresarios no veían valor añadido al desarrollo de software, preferían un paquete estándar en el que el coste del software fuese menory habitualmente descartaban cualquier tipo de desarrollo que pudiera aportarles mayor valor. Por el medio, intentamos un poco de todo, desde dar cursos de formación a empresas o cualquier colectivo, hasta llegar a acuerdos comerciales con otras entidades del sector y colaborar en el desarrollo de sus aplicaciones.

Los clientes entraban en la tienda con el fin de informarse sobre los costes de un ordenador personal y demandaban al mismo tiempo que les instalásemos todo el software necesario, (sistema operativo, paquete de ofimática, antivirus, etc.), por supuesto totalmente ‘gratis’, yo me indignaba con esto, pues la mayor parte rehusaban a realizar la compra en nuestra empresa debido a que otras, les ofrecían estos servicios de “valor añadido”.

Recuerdo que yo entonces era un “soñador”, soñaba con tener una empresa, con trabajar duramente y en pocos años, aspiraba a vivir cómodamente, cuando me hablaban de dinero yo les respondía que para mí no era importante, que el dinero era lo de menos, el dinero ya vendría después del trabajo, nunca me preocupo especialmente. Después de un tiempo, me di cuenta de que la empresa había tomado un camino muy distinto del que tenia planeado, nos habíamos convertido en una empresa de informática habitual y habíamos dejado de lado el desarrollo de software, lo único que podría diferenciarnos y aportarnos valor. Finalmente después de un tiempo y muchos problemas, abandone la empresa.

Este fracaso, me permitió más adelante, reflexionar sobre los errores que cometí.

Cuando conformamos la empresa no teníamos una idea clara del negocio, teníamos una idea general, pero no contábamos con un proyecto claro, ni siquiera con un pequeño estudio de mercado, nos lanzamos con un desconocimiento total, carecíamos de un plan estratégico, no teníamos un sector determinado al que atacar, ni una idea clara que seguir, tan solo, hacer lo que fuera para subsistir y luego, dependiendo de la situación que alcanzásemos, tomaríamos posteriores decisiones.

En principio, la idea era desarrollar software de gestión y más adelante, aprovecharlo para realizar algún vertical. Desarrollamos un programa similar a otros que ya existian en el mercado y que, aunque no era tan completo como el nuestro, cumplía con los objetivos básicos y logicamente al ser mas sencillo también era mucho más barato.

Destinamos la mayor parte de los recursos a desarrollar el software y posteriormente intentamos comercializarlo. Este fue uno de los mayores errores que cometimos, realizamos un producto, sin analizar el mercado ni a la competencia, sin recursos económicos, sin un sponsor, asumiendo que, como nuestro software sería mucho más completo que los demás, se vendería sin problemas. Es decir, primero producimos el producto y posteriormente intentamos comercializarlo. Al cabo de unos años y debido a este fracaso, deducí que lo mas adecuado seria invertir el orden, “vender y luego producir”, curiosamente el sistema LEAN se basa en una idea similar, fabricar en base a la demanda, es decir ‘vender antes de producir’.

No teníamos un plan comercial viable. Contar con un estudio de mercado, para atacar a sectores en los que la competencia no estuviera presente, hubiera sido mucho más inteligente que intentar competir con un producto que ya existía en el mercado contra empresas solventes, mucho mejor posicionadas que nosotros, en un mercado que dominaban desde hacía algunos años. Estoy convencido de que si hubiéramos dedicado un poco de tiempo a estudiar y analizar en detalle el mercado, podríamos haber llegado a tener una idea clara de negocio, posteriormente lo pude ver claro con empresas que triunfaron, porque orientaron sus desarrollos a hacer programas de gestión a Concesionarios, Hoteles, Abogados, Dentistas y otros sectores que no disponían de ninguna solución de software.

El desconocimiento del mercado hizo, que cuando terminamos el desarrollo, nos encontramos con que la mayor parte de nuestros posibles clientes, se había decantado por otros productos más sencillos y baratos. La competencia opto por hacer todo lo contrario, desarrollo un producto sencillo que no requiriese mucho tiempo y lo puso en el mercado un precio mucho menor, de esa manera, comenzaba a retornar parte de la inversión y poco a poco iban aumentando la funcionalidad, además, sus clientes se convertirían en usuarios potenciales de sus versiones más avanzadas que habitualmente tenían precios mucho más elevados. Esto les aporto feedback para mejorar sus versiones, ‘me acuerdo de Scrum con las entregas continuas de software…’, la penetración era mucho más rápida, porque al cliente no le importaba desembolsar un poco de dinero por el software y posteriormente si sus requerimientos aumentaban podrían ampliar a versiones más avanzadas, todo esto, hizo que en poco tiempo nuestro producto fuese menos competitivo. La estrategía comercial de nuestros competidores fue mucho mas acertada.

Los programas que realizaba la competencia, cubrían tan solo aspectos básicos que la gente necesitaba, la mayor parte de los clientes empezaba a trabajar con computadoras personales con lo que un programa muy complejo hubiera fracasado. Nos ocurría a menudo que cuando alguien veía nuestro programa comentaba: ‘es excelente, pero tiene demasiadas opciones…’, a mi no me hacen falta tantas, nunca modificare un informe, no sé si podre manejarlo. Resulto que nuestro mercado, no estaba preparado para un producto tan complejo. Nos olvidamos de estudiar los requerimientos de los clientes, en lugar de esto, intentamos hacer un programa que cubriese todas las necesidades existentes, esto hizo que nuestro producto fuese mucho más complejo de entender y manejar.

Nos olvidamos de evaluar el tiempo de desarrollo, el tiempo es un factor determinante, el desarrollo duro más de dos años, en este periodo, la competencia se hizo con un mercado potencial de clientes muy grande y que mas adelante fue imposible de recuperarar, la mayoria ya se había habituado a su uso, y nuestros competidores iban incrementando la funcionalidad en base a la demanda de los clientes.

Como necesitábamos dinero para mantener la empresa y no logramos que el software desarrollado se vendiese como queríamos, intentamos buscar una empresa que estuviera interesada en comercializar el producto, viajamos a Madrid y se lo ofrecimos a varias, la mayoría rehusaba, pues ya contaban con algún producto que si ser tan completo, conocían perfectamente y les resultaba fácil adaptarlo a las necesidades de sus clientes, aunque hubo un par de ofertas serias de compra que pasaban por hacerse con todo el código fuente y controlarlo completamente. Las ofertas fueron de bastante dinero, pero no quisimos renunciar a su control, así que lo descartamos. Si hubiéramos vendido el producto, el dinero nos hubiera permitido continuar, desarrollando la empresa durante unos años cómodamente y podíamos haber dedicado otros recursos a realizar otros productos, pero no queríamos desprendernos de un programa que considerábamos como uno de los mejores del mercado y éramos demasiado ambiciosos, queríamos hacer mucho en muy poco tiempo.

A partir de aquí, para subsistir nos dedicamos a vender hardware, dar soporte y mantenimiento a empresas, formación, instalación de redes, etc., en fin todos aquellos servicios que dan las empresas de informática, pero en esto, no aportábamos ningún factor diferenciador importante.

Además de esto, nuestra inexperiencia hizo que en varias ocasiones, aceptásemos proyectos en los que posteriormente descubrimos que los clientes eran auténticos profesionales del engaño, aceptaban el presupuesto sin pestañear, pero a la hora de cobrar descubríamos que muchos nos engañaban, recuerdo que hubo un proyecto, en el que después de finalizarlo nos enteramos que el cliente estaba en la ruina y que debía dinero a mucha gente realizando prácticas similares, no creáis que fue solo un caso, sufrimos varios, alguno de ellos, de importantes sumas de dinero que nos complicaron mucho la vida. La importancia de realizar un estudio del cliente es fundamental, cobrar a la firma de un contrato un porcentaje del proyecto y asegurarnos de la solvencia del cliente son aspectos muy importantes que se deben realizar antes de aceptar cualquier proyecto, existen empresas como Crédito y Caución que aseguran el pago de un determinado porcentaje de la cantidad facturada a cambio de un porcentaje de la operación.

No logramos convencer a las empresas de que nuestros servicios ofrecían valor añadido, les ofrecíamos lo mismo que las demás, algo que los demás hacían igual que nosotros. Y, ¿Por qué una empresa va a confiar en alguien que no conoce y que además no ofrece nada nuevo ?…. Estaba claro, nuestro objetivo inicial había variado, ahora ya no desarrollábamos software, tan solo hacíamos lo que fuera para subsistir y nos olvidamos del verdadero objetivo de nuestra empresa.

No supimos analizar bien nuestros costes, cuando comenzamos la actividad nos dimos cuenta de todos los gastos que debíamos soportar, pago de autónomos, IAE, gastos de luz, agua, teléfono, nóminas, seguros sociales, mobiliario, acondicionamiento del local, declaración de IVA, seguro del local, asesoría contable, alarma, gastos por líneas de crédito y transacciones bancarias, recuerdo que pusimos un aparato para pagar con tarjeta, nos enteramos que VISA llega a cobrar un 4 % por cada transacción que realicen los clientes, recuerdo que algunos productos informáticos apenas tenían ese marguen comercial. Os aseguro que, por pequeño que sea el negocio, la lista de gastos es interminable, y claro, podéis esperar ‘sentados’ que los Ayuntamientos y otros Organismos Oficiales os ayuden, lo único que les interesa es ampliar sus ingresos. Así que debéis tener claro todos los gastos antes de comenzar vuestra actividad.

No contábamos con una estrategia comercial seria, no podíamos permitirnos un agente comercial especializado, vender software o servicios informáticos requiere profundos conocimientos técnicos y comerciales, encontrar un comercial en este sector es muy complicado, al carecer de medios, hizo que tuviésemos que dedicarnos a realizar esta labor, carecíamos de la suficiente experiencia, el desconocimiento del perfil de los empresarios de la zona, que no creían como yo, en el valor que podría aportarles el software a medida, hizo que la mayor parte de las empresas rehusasen a aceptar nuestros servicios y que posiblemente un comercial con experiencia podría haber triunfado donde yo fracase.

No contábamos con un sponsor que financiase nuestro proyecto y desde luego no teníamos medios económicos, con lo que solamente subsistir mes a mes ya era un logro para nosotros, pero siempre nos obligaba a estar en la cuerda floja, si un mes no realizábamos el objetivo de ventas, la empresa se tambaleaba y varias fueron las veces que estuvimos a punto de cerrar, dedicábamos todas nuestras energías a llegar a fin de mes.

No dedicábamos tiempo a innovar, a poner en la mesa ideas diferentes y realizar algo que nos distinguiese de nuestros competidores. Esto hizo que nos incorporásemos a un mercado en el que nuestros competidores tenían mucha ventaja, disponían de mayor experiencia y habitualmente contaban con una cartera de clientes. La mayoría no tenían que preocuparse por subsistir, con lo que podían contar con más recursos para competir en el mercado.

Debido al poco tiempo que teníamos, empezamos a dejar de formarnos, tan solo dedicábamos un poco de tiempo cuando podíamos, así que con el tiempo fuimos perdiendo valor en nuestro mercado, pero nuestro trabajo no daba para más, así que pasamos de ser desarrolladores a ‘empresarios de poca monta’.

Los problemas económicos, administrativos y comerciales fueron aumentando y hacían que dedicásemos prácticamente todos nuestros recursos a subsistir y apenas teníamos tiempo para pensar, no nos paramos a ver cómo mejorar, como hacer cosas que nos aportasen valor, nos movíamos por impulsos, a petición de la demanda de algunos clientes que tan solo nos permitían subsistir y con el único objetivo de llegar a fin de mes. Nos fue prácticamente contratar personal adicional, desde técnicos especializados hasta comerciales con conocimientos del entorno, esto hacia que tuviésemos que hacer de todo, desde barrer hasta encargarnos de realizar presupuestos de equipos informáticos, con lo que fuimos dejando en otro plano aquello que nos podría diferenciar de los demás.

No logramos convencer a otras empresas del sector de que la colaboración podía hacer que estableciendo ciertas reglas de compromiso, nuestros márgenes comerciales mejorasen y ofreciesen mayor valor añadido. La incapacidad para llegar a acuerdos con nuestros competidores hizo que tuviésemos que renunciar a la mayoría de la venta de software y esto elimino un mercado que podría habernos ayudado en nuestros objetivos.

La parte positiva, es que al final, este y otros fracasos, me ayudaron a lo largo de toda mi trayectoria profesional a entender mejor cómo se comportan los mercados, la importancia del cliente y la competencia, de la colaboración, del trabajo en equipo, de la innovación, que de otra forma, difícilmente hubiera podido aprender. He tenido el privilegio de poder “intentarlo”, algo que muchas personas ni siquiera se han atrevido o que su condición económica no se lo permitirá a lo largo de su vida, he aprendido mucho de las personas que nos rodean y que los errores, nos enseñan aspectos que de otra forma, serian muy difíciles de aprender, por eso pienso, que aquel que ha fracasado, tiene más valor que él no lo ha hecho nunca, los errores del pasado, nos enseñan cómo mejorar nuestro futuro y a no cometer los mismos errores, de ahí la importancia del conocimiento de la historia.

He aprendido que en la colaboración y en el valor de las personas está la clave de todo, en que pensar antes de hacer las cosas es mucho más importante que hacerlas y luego pensar…, aunque a veces haya que arriesgarse, que el trabajo en equipo, la formación continua, la innovación y por supuesto, ‘los fracasos’, son aspectos que conducen al éxito.

Este es un sector proclive al cambio y la innovación y tenemos un mercado inmenso esperando a ser explotado, así que animaros, no tengáis miedo al fracaso, pero cuidado, no os engañéis, nadie os va a regalar nada, el dinero es el primer objetivo de una empresa, que una empresa tenga éxito pasa solo por una cosa: ganar dinero. Si la empresa no gana dinero, no podrá alcanzar sus objetivos, para poder establecer una empresa debemos tener un plan establecido que asegure la viabilidad de esta, desde el principio, sobre todo al inicio, que es, cuando más falta nos va a hacer.

Mis fracasos me han enseñado mucho, si tuviera que poner en marcha una nueva empresa de desarrollo de software, desde luego haría cosas muy diferentes, algunas de ellas serian:

Buscar una idea y desarrollarla, intentar que esta sea innovadora o que aporte algo que marque la diferencia frente a vuestros competidores, establecer una línea de negocio clara realizando un plan estratégico con su análisis de costes y beneficios, estudiar las ventajas e inconvenientes del negocio, analizar cómo, después de un tiempo, podéis dotar a vuestra idea de mayor valor añadido, trazar un par de planes alternativos por si no funciona como teníais planeado, realizar un pequeño estudio de mercado estudiando a vuestros posibles clientes y el entorno en el que se encuentran, si es posible contar con alguno de ellos para comenzar, compartir los riesgos con un sponsor, estudiar a vuestra competencia antes de actuar y el mercado al que va destinado vuestro producto, compartir vuestra idea con alguna persona con experiencia en el sector para obtener otros puntos de vistas y evaluar los posibles riesgos que pueden aparecer y que de otro modo desconoceríais, hay que tener en cuenta que cuando alguien tiene ilusión por una idea solo ve la parte positiva, debemos contar con opiniones externas para contar con un punto de vista mas objetivo y me atrevería a decir ‘mas real’. Así mismo, es muy importante rodearse de un equipo adecuado, contar con personas preparadas que sean innovadoras, proclives al cambio y que compartan la visión de la empresa. Es también muy importante que los miembros del equipo mantengan una buena relación y tengan un nivel de educación aceptable, pues el acercamiento siempre da lugar a roces. En el área del desarrollo, el tiempo es un factor determinante, apostar por desarrollos de larga duración es un riesgo muy alto, es mucho mejor resolver las necesidades básicas y posteriormente ir incrementando la funcionalidad y optimizando el producto, esto permitirá retornar la inversión más rápido y disminuir vuestros riesgos.

En resumen, ‘pensar antes de actuar’, ‘vender antes de producir’, ‘innovar’, ‘apostar por el valor del equipo y la colaboración’, ‘reducir vuestros riesgos’, ‘tener en cuenta que el tiempo, es un factor determinante’.

Espero que mis experiencias os ayuden a no cometer los mismos errores, si lo logro, habré fracasado con éxito.

Cuestión de velocidad…

Velocimetro

Creo que todos los desarrolladores, alguna vez hemos estado obsesionados con la velocidad, la velocidad es un tema importante, incide en prácticamente todas las facetas de la computación, realizar un programa veloz normalmente marcará el éxito o el fracaso de un desarrollo, Google es un claro ejemplo de esto. Si lo comparamos con la velocidad de un coche, la verdad es que no tiene mucho que ver, prácticamente todos los coches pueden viajar a 100-120 km/hora, lo suficiente para realizar cualquier viaje, por grande que sea.

En el ámbito de las conexiones de red comenzamos con velocidades de 50 bps que utilizaban los antiguos teletipos, en cambio ahora la mayoría de los canales de comunicaciones, desde una simple Ethernet con velocidades de  1000 Mbps full dúplex, hasta las Wifi que con la nueva norma n podrán llegar a los 300 Mbps. El avance es espectacular hemos pasado de 300 bps al descargarnos algún archivo de las primeras BBS a disponer de ADSL con velocidades de hasta 20 Mbs.

Me pregunto que pasara cuando la velocidad de internet, llegue a ofrecernos una velocidad suficiente para poder ejecutar cualquier tipo de servicio con fluidez, y como sucede hoy en día con las redes de fibra en la que ni los discos duros más veloces sean capaces de procesar. Existe hoy en dia algunos lugares, como Japón, donde se pueden conseguir velocidades de hasta 100 Mbps, lo suficiente como para hacer casi cualquier cosa, es cierto que para ello todas las infraestructuras de internet tendrán que readaptarse, pero a la velocidad que esto se mueve apenas notaremos el cambio.

Pese a que el incremento de la velocidad ha sido paulatina, las necesidades han ido aumentando quizás hasta más que la propia velocidad, pasamos de descárganos algún pequeño fichero de 15 Kb desde las antiguas BBS a varios Gygabytes de alguna aplicación, el video bajo demanda, las redes P2P, voz Ip y otros servicios han ido surgiendo a medida que la velocidad a permitido su funcionamiento. Los avances de velocidad en los procesadores, la utilización de múltiples núcleos, la incorporación de grandes procesadores en las tarjetas de video han permitido que en poco tiempo hayamos pasado de programas simples a modernas y complejas aplicaciones que nos permiten trabajar con objetos 3D, video, etc.

Sin embargo, después de tantos avances, algunos programas parecen cada vez más lentos, creo que todavía hoy en día el área del desarrollo en general no ha sido capaz de asumir la velocidad del hardware, el ejemplo más claro es que las aplicaciones de 64 bits todavía no han despegado. Actualmente se acaba de presentar la programación paralela destinada a aprovechar todos los núcleos de los procesadores que nos permitirá conseguir mejores ratios de rendimiento y aprovechar todas las ventajas de nuestro hardware, veremos cómo evoluciona y si le sacaremos el partido que merece.

Me pregunto, cuándo internet permita conseguir velocidades de 100 Mbps o más como en Japón, si la velocidad dejara de tener tanta relevancia como hoy en día, la mayoría de los programas en Internet, incluso ayudados de nuevas tecnologías como Ajax, Silverlight, Flex y otras, todavía no permiten una interacción muy fluida con los usuarios, si bien han mejorando mucho, pero en poco tiempo, creo que tal y como sucede con los coches esto dejara de tener tanta relevancia. Pienso que estará al alcance de todos obtener la mayoría de servicios de una forma fluida, desde tv bajo demanda con alta calidad, algo que hoy en día ya es una realidad con la mayoría de proveedores de Internet que ofrecen servicios de TV, manejar objetos 3D, acceder a recursos compartidos como si de una red Ethernet se tratase, utilizar servicios de voz IP sin interferencias y todo el conjunto de servicios que hoy en día utilizamos mejorados por las capacidades de la red.

En este supuesto, para el que creo, no queda mucho tiempo, pienso que las arquitecturas volverán de nuevo a reinventarse ya que la capacidad de comunicación, permitirá que cualquier programa tanto Web como de escritorio tenga una capacidad de comunicación prácticamente ilimitada similar a nuestras redes de trabajo locales.

Estoy convencido de que el Software as Services (SAAS) es el futuro, y la mayor parte de los programas que existen, pasaran tarde o temprano a alojarse en la red, este paso masivo de aplicaciones marcara un antes y un después en nuestra vida, ya que la mayoría de los servicios pasaran a administrarse por especialistas y el coste de su mantenimiento bajara progresivamente, esto permitirá que de algún modo nos podamos abstraer de las necesidades de hardware y software necesario (actualizaciones, copias de seguridad, gestión de errores e incidencias, mantenimiento, etc). Creo que estos servicios serán mucho más baratos que contar con una infraestructura propia y por ello serán utilizados de forma masiva.

Uno de mis sueños y creo que el de mucha gente es la de desarrollar un programa sin demasiado esfuerzo que sea multiplataforma y que funcione por cualquier canal de comunicación establecido. Espero que con el aumento de la velocidad y de la progresión del SAAS esto se convierta en una realidad muy pronto.

En España, como no podría ser de otra forma, seguimos por debajo de la media de los países Europeos en velocidad y precio del ADSL, increíble, nos gana hasta Portugal, espero que poco a poco nos vayamos poniendo al día, ya que la importancia de la velocidad en Internet va a ser un punto clave para que podamos evolucionar con todas estas tecnologías. Os dejo la tabla comparativa del 2008.

clip_image001

Pienso que el Grid Computing se vera tambien beneficiado por el aumento de velocidad, como sabeis el Grid Computing es una tecnología que permite acceder a una gran capacidad de proceso y otros recursos utilizando equipos distribuidos, tal y como realiza Google con sus búsquedas. Uno de los ejemplos más antiguos es el proyecto SETI para la búsqueda de vida extraterrestre que utiliza ordenadores personales de la gente que quiera participar en el proyecto, para procesar datos, creo que el aumento de velocidad hará que esta tecnología vaya asentándose cada vez más.

Parece que está de moda hablar de la Nube, y a mi juicio todo indica que Azure será el primer paso para asentar todas estas ideas que comenzaron hace algunos años cuando los Web Services empezaron a tomar mayor relevancia y que ahora debido sobre todo al aumento de la velocidad se pueden hacer realidad.

Todo indica que Internet continuara progresando de forma exponencial en los próximos años y su importancia será cada vez mayor, en pocos años, quizás, hasta cobre vida propia…, ya hay televisiones que permiten conectarse a internet, pienso que dentro de poco se conectaran desde los coches hasta las cafeteras y lavadoras, veremos lo que nos depara el futuro.

Aún con esto, sigo teniendo mis dudas:

¿Dejara de tener importancia la velocidad tal y como ha pasado con los coches o el aumento de los requisitos seguirá aumentando conjuntamente con la mejora de la velocidad como ha sucedido hasta ahora?

¿Se asentara definitivamente el Grid Computing y dejaran los grandes servidores de tener tanta importancia?

¿Dejaran de utilizarse masivamente los protocolos de comunicación soap y tecnologías como http y xml, para dejar paso a protocolos más avanzados en forma binaria?

¿Lograra el SASS comerle el terreno a las aplicaciones locales y se asentara definitivamente para convertirse en la plataforma más utilizada?

Espero vuestras opiniones…

Un saludo.

Innovar sí, pero como…

A raíz del post de Rodrigo hablando sobre innovación, me he animado a escribir este artículo, la verdad es que el tema me apasiona, recuerdo una conferencia sobre trabajo e innovación hace un par de años, en el que el ponente , un Consejero de Telefónica y varias empresas importantes de España, hablaba sobre la necesidad de innovar, en concreto comento un caso de una Empresa Catalana galardonada con un premio Europeo a la entidad más innovadora, comentaba que la empresa disponía de un equipo de personas que se pasaban el día estudiando la viabilidad de nuevos productos, los desarrollaba y empezaba a comercializarlos, y cuando veían que el producto llegaba al máximo de ventas, es decir su curva de ventas comenzaba a descender automáticamente lo retiraba del mercado, recuerdo que a mí y creo que a muchos otros, se nos quedo cara de tontos, pensando cómo, cuando un producto alcanza su máximo de ventas lo abandonaban, la idea subyacente es sencilla, era en este momento cuando la competencia y otros factores externos empezaban a comerles terreno, y porque luchar contra algo imparable, siempre habría alguien que lograría realizar el producto más barato e incluso mejor, simplemente lo retiraban y pasaban a dedicar todos sus esfuerzos a desarrollar nuevos productos.

Recuerdo una reunión en una empresa, donde se habría un debate para ver cómo entre todos los componentes, la mayor parte responsables de cada uno de los Departamentos podían aportar ideas para intentar mejorar una situación delicada, la mayor parte de los componentes no decían nada, en cambio, algunos empezaron a lanzar ideas, mejorar el departamento comercial, intentar fabricar otros productos con los medios productivos que tenían, abrir nuevos mercados, eliminar los canales de distribución para llegar al cliente final y obtener mayores beneficios, realizar acuerdos con competidores o con empresas relacionadas con el sector, mejorar la calidad para poder acceder a mercados más exigentes, adquirir alguna empresa de la competencia, etc. La mayor parte de estas ideas eran rebatidas rápidamente por algunos miembros descartándolas rápidamente aduciendo que algunas se habían puesto en marcha y habían fracasado años atrás, que no veían su rentabilidad inmediata y que otras simplemente eran totalmente erróneas por el desconocimiento de las personas que las planteaban y que desconocían el mercado. Al final todas y cada una de las ideas se fueron descartando y se llego a la conclusión de que lo mejor sería ‘ahorrar costes’, si ahorran costes podrían continuar manteniendo un nivel de beneficios aceptable y aguantar el tirón en espera de tiempos mejores. Para ello deberían optimizar algunos procesos con los que trabajaban, reducir los gastos de algunos departamentos, paralizar ciertas inversiones, seguramente reducir parte de la plantilla, etc.

No digo que en la reunión no se llegaron a conclusiones que pudieran aportar mejoras a la empresa, pero lo cierto es que la palabra innovación se esfumo… y ¿por qué?, por el miedo a nuevas inversiones de dudosa rentabilidad, a apostar por algo sin la suficiente seguridad, en resumen por el miedo al fracaso.

Creo que este es un claro ejemplo de lo que ocurre con muchas empresas actualmente, se agarran a un clavo ardiendo con tal de no cambiar su negocio, la resistencia al cambio es el mayor enemigo de la innovación, aceptar que un negocio que ha funcionado durante muchos años, ya no es rentable y que hay que hacer cosas diferentes es algo muy difícil de asumir. Incurrir en proyectos que pueden fracasar de dudosa rentabilidad es algo que la mayoría suele reusar. Según mi opinión, creo que la mayor parte de las ideas que se presentaron seguramente podrían haber fracasado, pero estoy seguro de que si entre todas, solo una llegase a buen fin, seguramente la situación de la empresa hubiera cambiado considerablemente.

Para Innovar debemos arriesgarnos, debemos escuchar las ideas de los demás por absurdas que estás nos parezcan, debemos eliminar aquellas reglas que dicen, porque hacerlo de otra forma si de esta siempre nos ha funcionado bien o planteamientos como, ‘bueno, nosotros no vamos muy bien pero fíjate en los demás…’.

Para Innovar debemos dedicar parte de nuestro tiempo productivo a pensar cómo hacerlo mejor, como sacar valor añadido, como mejorar nuestro trabajo, si no nos paramos a pensar cómo mejorar, jamás lo haremos.

Desgraciadamente las empresas suelen tener un objetivo que les impide ver más allá, ‘la rentabilidad de los proyectos’, si de antemano no presentamos un proyecto rentable será muy difícil apostar por él, convencer de esto a los directivos de las empresas es algo muy difícil de conseguir. Lo primero que hacen es preguntarse: ya, pero y ¿si no sale bien?… ¿cuánto dinero nos va a costar?, estoy desacuerdo en que la rentabilidad es un factor muy importante, pero para innovar tampoco es necesario realizar grandes inversiones, hay muchas formas de minimizarlas realizando proyectos pilotos, maquetas, simulaciones, estudios de mercado, o mejor vender la idea, convencer a un sponsor y llévala a cabo, si, se que suena como un sueño de hadas pero muchos proyectos han conseguido ver la luz siguiendo este método, comparte el beneficio y disminuye tus riesgos, pero si todo esto no es posible, siempre llegara un punto en que habrá que arriesgarse. Si aún así, no somos capaces de llevar a cabo el proyecto solo nos quedara una cosa por hacer,”nada”, esta es la opción más utilizada, y como es gratis y no cuesta ningún esfuerzo, a esperar como el avestruz que entierra su cabeza en la tierra cuando viene un león…

Todo esto, me hace preguntarme una cosa. ¿Somos los desarrolladores innovadores?, en mi opinión y después de más de 20 años de profesión puedo afirmar que no. Creo que la mayoría de nosotros destinamos la mayor parte de nuestro tiempo a aprender a utilizar nuevas tecnologías para no perder el tren, el constante bombardeo de las grandes empresas de Software como Microsoft, Google, Adobe y algunas otras, hace que estemos constantemente estudiando lo que ellos nos proponen, en mis 20 años, tan solo he realizado 3 o 4 proyectos que pudiesen definirse como innovadores y solo por la aplicación temprana de nuevas tecnologías de reciente aparición, en contraposición somos muy abiertos al cambio, estamos siempre en predisposición de adoptar nuevas tecnologías y cambios, pues nuestra profesión así lo requiere, pero realmente apenas innovamos nada, no hacemos nada diferente, tan solo copiamos aquello que nos proponen las grandes empresas de software, y en el mejor de los casos a veces lo mejoramos un poquito. En mi opinión para innovar deberíamos renunciar a estar siempre a la última y destinar parte de nuestro tiempo a proponer ideas, escoger alguna interesante y llevarla a cabo, en lugar de dedicar todo nuestro tiempo a aprender lo que nos proponen los demás, si bien es necesario estar al día, para no cometer el error hacer algo que los demás ya han construido, un error muy frecuente en nuestra profesión.

Deberíamos también dejar a un lado muchas de las reglas que aplicamos, cuando desarrollo, sobre todo en estos últimos años, tengo un pensamiento que constantemente me dice “demasiadas reglas”, el desarrollo es cada vez menos fluido, menos intuitivo, esto, me hace preguntarme si estaré haciendo las cosas bien, en mi opinión demasiadas reglas limitan la innovación ya que en muchos casos la rigidez de algunas de ellas y el tiempo que destinamos a aplicarlas, evitan que destinemos nuestros recursos a innovar o ser mas creativos.

Debemos hacernos estas preguntas de forma habitual, ¿Cómo puedo mejorar?,¿Cómo puedo hacerlo más rápido?, ¿Cómo puedo sacar mayor valor añadido?, y dedicar parte de nuestro recursos a responder a estas preguntas.

En general, el desarrollo de software de las grandes empresas de desarrollo es un área muy innovadora, ellos han entendido mejor que nadie la necesidad de innovar constantemente y por ello son ellos y no nosotros los que logran el éxito, y no me refiero solamente a obtener un buen salario…

El área del desarrollo de software es un mercado sumamente competitivo, pero con gran potencial, no hay más que fijarse en empresas que en pocos años pasan de no ser nada a cotizar en bolsa, en ver cuántos productos nuevos aparecen y otros que en poco tiempo desaparecen, como cambiamos de un año para otro nuestra forma de trabajar, como tenemos que obligatoriamente apostar por una formación continua para poder mantenernos en este mercado, pero no lo hacemos porque somos innovadores, lo hacemos porque es un requerimiento de mercado, me pregunto cuántos desarrolladores de los que escribimos aquí o de los que nos leen, realizan proyectos innovadores si no es por petición de un cliente, creo que muy pocos son los que llegan a alcanzar este status, que envidia tengo de Miguel Llopis que trabaja en el desarrollo de nuevas tecnologías y puede destinar gran parte de su tiempo a ser innovador.

Para innovar debemos trabajar en equipo, las relaciones personales son fundamentales para poner una idea en funcionamiento, saber convencer, incentivar y hacer participes a la gente de un equipo con una idea es algo fundamental, y estoy desacuerdo que la mayor parte de las veces hace falta la figura de un Líder que incentive y mantenga unido al equipo para llegar a obtener mejores resultados, si bien tener un objetivo común en el que todos los componentes creen puede hacer que esta figura se reparta entre todos los miembros del equipo, en un equipo innovador todos deben escuchar y debatir las ideas de los demás, la política de la empresa debe otorgar libertad en la toma de decisiones, conozco muchas personas a los que se les limita la capacidad de innovación en pro de la rentabilidad, así pues es necesario que todos desde el primero al último apueste por la innovación.

La necesidad es también un factor que nos llama a innovar, solo cambiamos cuando tenemos la obligación de mejorar, ponemos en marcha nuevas ideas cuando las que tenemos no sirven o no nos aportan lo suficiente, desgraciadamente en la mayoría de los casos, es, en estos momentos cuando es demasiado tarde.

Es curioso ver los gráficos de las patentes en España, está generalmente admitido que el número de solicitudes de patentes originadas en un país constituye un indicador bastante significativo de la situación de su sistema de I+D+I,

Fuente: http://www.oepm.es/cs/Satellite?c=Page&cid=1213455385201&classIdioma=_es_es&idPage=1213455385201&pagename=OEPMSite%2FPage%2FtplListaDocumentos&numPagActual=1

clip_image002

clip_image004

BSH Electrodomésticos España es la primera empresa industrial en solicitar patentes, con un total de 65 en 2008.

Solo la Empresa IBM, la que más patentes realizo en 2008 tiene 4000, observando estos gráficos no me estraña que nos encontremos en la situación actual, lo extraño es que no hayamos llegado antes.

Una cosa esta clara, España tiene mucho camino que recorrer y actualmente estamos a la cola de la mayor parte de países desarrollados, debido a que las políticas de formación y de I+D+I desde el gobierno y las empresas han sido desastrosas.

En estos tiempos que corren y creo que en un futuro cercano si no somos capaces de innovar, nunca llegaremos a tener éxito y tarde o temprano fracasaremos, el miedo al cambio, el riesgo de invertir en nuevas ideas nos impiden innovar, hay que enfrentarse a estos miedos para poder llevar a cabo nuevas ideas, la mayor parte seguro que fracasaran, pero con que tan solo una llegue a buen término merecerá la pena.

Creo que el fracaso conduce al éxito, hace muchos años que leía un artículo del Newsweek que decía que los empresarios de EEUU preferían contratar a alguien que hubiera establecido tres empresas y hubiera fracasado que a un candidato que tuviese un Curriculum excelente.

Innovar es hacer cosas diferentes, arriesgarse, no temer a fracasar, cuestionarse que aquello que funciona hoy, no lo hará mañana o que siempre se puede mejorar, y como decía Albert Einstein, si quieres cambiar algo no hagas siempre lo mismo…

¿Qué opináis?

Sobre el porqué utilizar metologías Agiles (Scrum) no es una moda…

Escribía el otro día David Arrollo (Ddaz) sobre si las metodologías agiles, en concreto Scrum estaban de moda, me he animado a realizar este post para plasmar mi opinión sobre este tema.

Como sabéis las metodologías ágiles evolucionaron sobre el año 1990 en respuesta a los métodos estructurados y estrictos extraídos de los modelos de desarrollo en cascada, aunque sus principios se establecen en el año 1986, no es hasta hace unos pocos años que se empieza a adoptar por multitud de empresas.

Pienso que la adopción masiva de metodologías en el área del desarrollo de software no es una moda tal y como comenta Fran en su blog, creo que cada vez mas empresas están adoptando estos métodos de trabajo con el único fin de mejorar su gestión optimizando sus procesos para intentar lograr ser más competitivos. Hasta hace relativamente poco a la mayoria de empresas  todo esto les daba igual, sobre todo debido a la bonanza económica, pero los mercados, cada vez más difíciles y competitivos, y la crisis actual estan provocando que algunas entidades se centren en la búsqueda del ahorro de costes y la mejora de la rentabilidad y poco a poco estas empresas se están dando cuenta de que mejorar su gestión interna es un aspecto cada vez mas importante, que puede llegar a marcar la diferencia, una ahorro de tan solo un 10-20 % puede hacer que la empresa sea competitiva o no.

No hace muchos años el conocimiento de los procesos en las empresas era aglutinado por unos pocos, algunas se han comenzado a dar cuenta de que el verdadero valor recae en todas las personas que la conforman y que en la mayor parte de los casos son los operarios de las maquinas, los técnicos cualificados y personas cercanas a los procesos los que más saben del trabajo que están realizando y consecuentemente los que conocen mejor como poder mejorarlo. Esta situación está provocando que las empresas empiecen a contar con la opinión de estas personas que antes eran meros ejecutores de los procesos para formar parte activa en la toma de decisiones.

Algunas metologías de trabajo, en este caso “Scrum”, ya que es la mencionado por Fran, explota precisamente estas ideas, basan su gestión en la creencia de que su valor esta en las personas que conforman los equipos de trabajo tal y como comento en el post y la reducción de la burocracia apoyada en la simplicidad.

Pero esto no es nada nuevo, en los sistemas Lean, los equipos de mejora continua, trabajan con la misma idea que la mayor parte de las metologías agiles, intentan eliminar la burocracia y optimizar los procesos en base a sus objetivos más cercanos ayudados por las personas que realmente los conocen en profundidad.

Algunas empresas de desarrollo de software están comenzando a adoptar una metodología por necesidad comercial, porque para sus clientes es un requisito, muchos organismos oficiales están comenzando a demandar la adopción de metodologías de trabajo cuando contratan un desarrollo, pero esto no es por moda, si no por necesidad, por la necesidad de evitar errores cometidos en el pasado, con aplicaciones que han sido un autentico fracaso, que han costado autenticas barbaridades, que han pasado de una empresa a otra y nunca han funcionado, estos errores y fracasos están haciendo que muchos de estos organismos hartos ya de “tirar” el dinero en informática empiecen a exigir la adopción de mejores sistemas de trabajo que les aseguren la viabilidad de sus proyectos.

Otras entidades realizan la adopción simplemente, porque obtener un certificado en una determinada metodología les hará distinguirse de sus competidores. En este último caso lo comparo con la ISO 9001, conozco varias empresas que únicamente disponen de este certificado únicamente por una razón comercial o porque alguno de sus clientes se lo exige, que lejos de hacerles mejorar tan solo les aporta burocracia y que al final desgraciadamente certificarse se convierte en una cuestión de dinero, con dinero se puede contratar más personal para gestionar todos los requisitos, se puede invitar a comer a buen restaurante al responsable de la certificación e incluso en algunos casos se puede llegar a “comprar” la certificación, he visto empresas con la ISO 9001, que ni siquiera son capaces de gestionar el stock de su almacén o encontrar un pedido en sus ficheros , desgraciadamente esto ocurre con multitud de empresas y hace que al final el valor de estas “certificaciones” quede en entredicho. También he visto algunas empresas que le han sacado valor a este tipo de certificaciones, con ellas han aprendido a gestionar de forma más adecuada sus recursos. En cualquier caso con certificación o no, todas tienen una razón para su adopción, si bien es cierto que la mayoria lo único que buscan es un título que avale lo bien que trabajan.

En cambio otras ven en la adopción de las metodologías de trabajo una forma de llegar a ser mas “competitivos”, mejorando su gestión interna y evitando cometer errores. En el área del desarrollo de software venimos arrastrando desde hace mucho tiempo una serie de problemas que además de ir minando un mercado de clientes cada vez mas descontentos, hacia que el coste de los desarrollos de software aumentase de forma exponencial, en muchos casos los proyectos se convertían en trabajos de dudosa rentabilidad y en otros, eran los clientes los que debían asumir los costes derivados de su mala planificación. Algunos de los problemas más habituales vienen derivados de estimaciones erróneas, problemas de trabajo en equipo, relaciones con los clientes, gestión de errores, gestión de versiones, cambios de contexto, etc.

Las metodologías ágiles nacen para dar solución a todos estos problemas, se conforman como una necesidad para todos aquellos que desarrollamos software, marcan las pautas y las reglas necesarias para poder minimizar todos estos problemas. No quiere decir que seán la solución mas adecuada, serán mejores o peores en base a las necesidades, capacidad y funcionamiento de cada empresa, y estará en su mano sacarles verdadero partido.

Scrum se conforma como una metología sencilla de aprender, ofrece gran valor añadido sin demasiado esfuerzo, eliminando la burocracia y centrándose en la productividad a través de iteracciones cortas, el valor del equipo, la gestión de las estimaciones y la relación con el cliente, hacen de Scrum una metrología facil que puede resumirse en una hoja y que es simple de adoptar si se cree en ella tal y como explica Jorge Serrano en Explicando scrum a mi abuela o Rodrigo en Porque me gusta Scrum, para hacerlo, no es necesario ningún tipo de certificación, cualquiera puede aplicar Scrum, los requisitos son sencillos y las reglas, no demasiadas, es por ello que Scrum es una metodología que se centra en la mejora continua y que permite gestionar varios proyectos sin una burocracia y costes excesivos. Por estas razones y no por otras, creo que Scrum se está empezando a utilizar de forma masiva, aunque todavía son muy pocos los que la sacan partido de verdad.

Por otra parte las nuevas tendencias y formas de trabajar se están empezando a trasladar a muchos sectores industriales y laborales, no solamente a la informática, en mi empresa, por ejemplo, estamos implantando un sistema LEAN MANUFACTURING, pero no por la moda de Toyota, que desde luego ha influido enormemente en su adopción (de hecho actualmente es el primer fabricante de automóviles del mundo), ‘por algo será’, si no en la búsqueda de mejorar nuestro sistema de trabajo y ahorrar costes, en resumen hacer que la empresa sea más competitiva y que tiene muchas similitudes con las metodologías de trabajo que utilizamos en desarrollo, de hecho se utilizo como base de algunas. Al final todos buscamos lo mismo, mejorar la productividad, ahorrar costes, ser más competitivos, mejorar nuestra relaciones laborales con nuestros clientes y el trabajo en equipo, hacer entender a aquellos que nos rodean que el trabajo que realizamos es complejo y difícil y que cada vez es más importante mejorar nuestra gestión de proyectos y evitar muchos de los errores que venimos cometiendo desde hace años. Que utilicemos Scrum o cualquier otra metología que nos permita realizar esto es indiferente, la utilización de una metologías no garantiza el éxito del proyecto, tan solo nos marca las pautas para evitar errores e intentar llegar a ser más competitivos.

Las metodologías de trabajo proponen soluciones para resolver problemas comunes, es algo así como la aplicación de patrones de diseño, ¿ porque no utilizar una solución ya probada para resolver un problema similar?. Sin embargo cuando hablamos de diferentes metodologías, parece que se desencadene una guerra, si un fontanero tiene que instalar una tubería de cobre la forma de hacerlo será en base a los elementos y el entorno que tiene delante, en cambio si la tubería es de otro material seguro que el método es diferente, con las metodologías pasa lo mismo, habrá metodologías que se adapten mejor a un tipo de cliente y un entorno determinados y en otras que puedan suponer un autentico fracaso ya que las ideas de las metologías deben ser coincidentes con la política de la empresa, este es el factor que hace que muchas fracasen en su adopción, “adoptamos algo en lo que no creemos”, pero no tienen porque ser unas mejores que otras, tan solo se adaptaran mejor en base a la forma de trabajar de las empresas, el entorno y otros factores. En todo caso, nacen para ofrecernos soluciones a los problemas con los que tratamos habitualmente, en los que aspectos tan importantes como la estimación, la colaboración y mejora del trabajo en equipo son factores fundamentales que nos permitirán adaptarnos y ser más competitivos.

Lo verdaderamente triste es que parece que en algunos países estamos a la cola y que hablar de la adopción de metologías de trabajo provoca una gran controversia, creo que la mayor parte de las veces por desconocimiento total de lo que implica la adopción de estos sistemas de trabajo.Sin embargo, algunas personas y empresas, quizás las menos, se han empezado a dar cuenta de la importancia que tiene la adopción de estos métodos de trabajo, que nos permiten optimizar y mejorar nuestro ámbito laboral. Esto es fundamental para el área del desarrollo de software ya que la complejidad de los sistemas y las diferentes tecnologías conjuntamente con el progreso, hacen que el desarrollo de software sea una de las aéreas que más cambios sufren . Estoy seguro de que aquellas empresas que apuesten por mejorar sus sitemas de trabajo marcaran la diferencia, para las demás creo que sus días están contados, apoyado por la ley de Darwin, ‘solo los que mejor se adapten al medio sobrevivirán’.

En cualquier caso si queréis seguir el ejemplo de General Motors, aquellos que creáis que la crisis actual es un invento del gobierno o que las empresas van a seguir exactamente igual, independientemente de su forma de trabajar, no hagáis nada, seguir trabajando igual.

No digo que Scrum sea la solución a todos vuestros problemas, pero que es un buen punto de partida para acercarse a las metologías agiles, robusta y relativamente facil de adoptar frente a otras. Si no usáis ninguna, hará que en poco tiempo no podías vivir sin ella, así que animaros, esto no es una moda, es una necesidad para todos aquellos que queremos mejorar nuestra forma de trabajar.

Windows Presentation Foundation. El final de Windows Forms…

Últimamente cada vez leo más artículos que hablan sobre las ventajas de construir aplicaciones en WPF frente a la utilización de Windows Forms, para aquellos que no lo conozcan, WPF es una tecnología que nos permite aprovechar al máximo las características gráficas de nuestros equipos ofreciendo interfaces más ricas de las que estamos acostumbrados. El objetivo de Windows Presentation Foundation es proporcionar avances en el entorno de Windows que permitan crear interfaces que incorporen documentos, componentes multimedia, gráficos bidimensionales y tridimensionales, animaciones, características tipo web, etc.

Sobre la afirmación de que WPF marcará el final de Windows Forms, me parece arriesgada, aunque la evolución que está teniendo esta tecnología frente a Windows Forms no solamente desde Microsoft sino de la mayor parte de empresas de controles de terceros, me hace pensar hasta que punto es cierta esta afirmación.

En los últimos años Microsoft viene acostumbrado a sacar nuevas tecnologías casi por arte de magia y a relegar otras de la misma forma, lo cierto es que el cambio no es tan fácil como se pueda pensar, la adopción de una tecnología como WPF, cambia por completo la forma habitual que teníamos para desarrollar aplicaciones Windows Forms. Los diseñadores gráficos pasan a formar parte casi indispensable de los equipos de desarrollo si queremos sacarle todo el partido a esta tecnologia, si bien es cierto que la mayor parte de empresas dedicadas a desarrollar controles de terceros como Infragistics, DevExpress y otros están apostando seriamente por esta tecnologia  con la inclusión de Skins y controles que nos facilitaran mucho esta labor.

En mi opinión son muy pocos los sistemas de gestión que requieran hacer un uso intensivo de la interface gráfica, sin embargo, en algunos ámbitos como científico o el médico, las capacidades 3D y las animaciones permiten obtener información de forma más eficaz. También es cierto que la mayor parte de los sistemas de gestión actuales suelen tener carencias precisamente en este apartado.

Glenn Block de Microsoft afirma que WPF es de largo la solución recomendada para el desarrollo de aplicaciones de línea de negocio para un futuro inmediato.

Algunas ventajas de WPF son las siguientes:

  • Estilo potente y estructurado.
  • Facilidad para crear estilos y aspectos.
  • Soporta Windows Forms.
  • Es el futuro para el desarrollo de aplicaciones de Vista.
  • Tiene capacidad de reutilización del código existente.
  • Databinding avanzado, que permite enlazar datos con cualquier control.
  • Programación declarativa vs procedural.
  • Capacidades avanzadas para la Web. (WPF/E)
  • Apuesta clara de Microsoft para su implantación.

Desventajas

  • En muchas ocasiones vamos a necesitar el trabajo de diseñadores gráficos para beneficiarnos del potencial de WPF, lógicamente este será un coste que debemos repercutir a nuestros clientes.
  • Modificar código en AXML es un infierno o al menos para mí es bastante complicado.
  • Los requerimientos de los equipos en el apartado gráfico serán mayores, deben soportar DirectX y disponer de una tarjeta gráfica con suficiente capacidad, sin embargo, estos son la mayoría de los pc´s de hoy en día, aunque todavía existen muchos equipos, sobre todo portátiles que no soportan del todo estos requerimientos.
  • Al tratarse de la primera versión, tiene muchos aspectos en los que mejorar sobre todo en el apartado de los diseñadores de formularios y entorno gráficos. De hecho se encuentra aún en fase de desarrollo.
  • La curva de aprendizaje es alta.

¿ Debo migrar mi apliación a WPF ?

No hace mucho tiempo que Miguel Jiménez solicitó que le enviase algunos formularios de la aplicación actual que estábamos desarrollando para ver la posibilidad de realizar un proyecto paralelo de migración a WPF, lógicamente le envié algunos de los formularios más grandes y complejos que teníamos, su respuesta fue: buff estas pantallas con tantos controles, pestañas y funcionalidad para realizarlos con WPF, sería un trabajo demasiado arduo, no se hasta que punto merecerá la pena, tendríamos que dividir algunos para integrarlos en WPF, esto me hace pensar, si WPF está lo suficientemente maduro para abordar sistemas de gestión complejos y si realmente merece la pena realizar este cambio sin una necesidad comercial seria. Creo que existen muchos desarrolladores migrando sus aplicaciones a WPF, sin una razón que justifique la adopción de esta nueva tecnología, todavía son pocos los entornos de gestión empresarial que necesiten verdaderamente un cambio de arquitectura y que son incapaces de articular una necesidad comercial.

Lo cierto es que algunas de las interfaces que he probado son verdaderamente impresionantes, no solo en cuando a mejora del interface gráfico, la velocidad de refresco y la interacción con el usuario mejoran notablemente. Como ejemplo os dejo un par de pantallas de los controles que usamos.

image

image

image

¿ Cuanto apoyo le queda a Windows Forms ?, he leído en alguna parte que Microsoft solo está apostando por WPF ahora y manteniendo Windows Forms, si esto es cierto, WinForms esta condenado a desaparecer y deberemos centrarnos poco a poco en la adopción de WPF, por otra parte el número de aplicaciones existentes hoy en día, hará que el soporte de WinForms persista durante mucho tiempo.

En mi opinión WPF es una nueva tecnología que se está asentando en estos momentos y como tal, no carente de problemas. Su curva de aprendizaje para aquellos que venimos de Winforms es alta. Quizás el verdadero reto no este en aprender como usar esta nueva tecnología, sino en pensar cómo, a través de ella, podemos enriquecer las aplicaciones para alcanzar determinados objetivos, como mejorar la productividad, mejorar la interacción con el usuario, aumentar la satisfacción, mejorar el rendimiento, etc. No debemos olvidar que la adopción de WPF, tendra un coste muy alto si tenemos que incorporar diseñadores gráficos a nuestros equipos de desarrollo. En cualquier caso parece que Microsoft ha realizado una apuesta clara por la utilización de WPF, su adopción en nuevas herramientas como Visual Studio 2010 y el nuevo diseñador de WorkFlow así lo demuestran y que además de confirmarse, ya habria abandonado la mejora de Winforms, con lo que de una forma u otra estaríamos abocados a utilizarla tarde o temprando.

Por otra parte me quedan varias preguntas sin contestar que creo que son comunes a las de muchos desarrolladores y que me gustaría con vuestra ayuda resolver:

¿ Deberiamos comenzar a estudiar a fondo WPF, para la adopción de esta tecnología en un futuro cercano ?

Si tuvieraís que realizar un nuevo proyecto similar a los anteriores desarrollados en Windows Forms, ¿ utilizarías WPF o esperarías a nuevas versiones ?

¿ Sera WPF el sustituto definitivo de Windows Forms o tan solo una nueva tecnología para realizar programas diferentes ?

¿ Sera WPF una tecnología más, que quizas en poco tiempo se vea relegada por otras como Silverlight o que debido a su alta curva de aprendizaje o sus costes no lograra asentarse lo suficiente como para convertirse en el sustituto de Windows Forms ?

¿ Esta lista esta tecnologia para abordar desarrollos similares a los que venimos realizando en Windows Forms ?

¿ Si no tenemos ni idea sobre diseño gráfico o nuestro equipo no puede disponer de diseñadores, podremos sacarle partido a WPF ?, ¿ Tiene sentido utilizar WPF en estos casos ?

En fin, quizas os dejo mas preguntas que respuestas, pero confio que entre todos conformemos una idea mas clara de lo que es WPF y de lo que va a suponer esta tecnología en los próximos años.

 

Pd. Y pensar que todo esto comenzo con CSI….

Manual de detección del Australopithecus

image

Según la wikipedia, vivió aproximadamente hace 4 millones de años, al comienzo del Pleistoceno. Creerme todavía existe, yo sigo tropezando con alguno de ellos.

En mis primeros años profesionales dedicados a la informática (digo profesionales no porque fuera un profesional, sino porque intentaba ganarme la vida con este trabajo), no sé si debido a mi juventud o inexperiencia, me tropecé con innumerables especímenes de este género, la mayor parte convertidos en “Empresarios de éxito” con un nivel de formación y educación que no sobrepasaba al de los grandes simios.

Recuerdo una anécdota en especial que me llamó mucho la atención, todo comenzó con una reunión con un homínido de esta especie (aunque yo entonces no me había percatado de nada, es más, me parecía increíble todo lo que contaba), después de haberlo escuchado hablar durante varias horas sobre la importancia que tenía la informática para ellos, la necesidad urgente de dotar a su Empresa de medios adecuados para su gestión y escuchar frases como: “yo, me he hecho a mí mismo”, “cuando dejé la cueva, solo me lleve lo puesto”, “cazaba las aves con tiragomas y no con escopetas calibre 458 como ahora…”, etc. Después de la reunión, la entrega del presupuesto (“¿no sé por qué?, si los informáticos no tenemos derecho a cobrar por nuestro trabajo.”).

Enseguida vi como frunció el ceño, me miró con cara de asombro y pocos amigos y me dijo:

– después de nuestra conversación no has entendido nada, (“claro, si yo vengo aquí a aprender, no a trabajar, gracias Dios por esta oportunidad…”),

– continuó: esto no es lo que esperaba de ti, pensaba que eras un tipo inteligente, este proyecto tiene valor añadido, si realizas el programa podrás vendérselo a todas las empresas del sector en las que estoy muy bien considerado, tienes que mirar esto con “perspectiva”.

– ¿Pero como podéis cobrar tanto?, joder vosotros los informáticos estais hechos de otra pasta y mirando a la secretaria le comento: ¡mira!, estos “ingenieros” que acaban de salir de la facultad y no saben hacer la “o” con un canuto, quieren cobrarnos hasta por respirar…

– Incauto, trate de explicarle las razones del coste del proyecto, y que valorar las 300 horas de trabajo por 4 gallinas, media docena de buitres leonados, un cráneo de mapache y un cuerno de alce, no era ni con mucho un gran presupuesto, pero claro no tenía “perspectiva”, finalmente dijo: bueno ya te llamaremos… Me fui pensando: “¿me habré pasado?, ¿quizás tuviese razón?, tendría que haberle aceptado solamente 1 cabra y el cuerno de alce, al fin y al cabo después podría comercializarlo en otras aldeas…”.

Paso bastante tiempo y el “eslabón perdido” vuelve a llamar y me dice: ¿te acuerdas de mí?, pues nada, que me he decido por fin y voy a contratar tus servicios y vuelta a otra reunión interminable en la que aguanto estoicamente sus logros y conquistas, ahora la necesidad de tener un sistema informático es imperiosa, ya que cometió el error de “contratar” a un amigo del primo del tío de la novia de su excuñado que había trabajado en la cabaña del Tio Tom y en su tarjeta decía “Product Manager”, además, era campeón del mundo en tiro con arco. El desgraciado, sin motivo aparente le había dejado en la estacada. Seguimos hablando y comento: “bueno, pero, lo del presupuesto aquel, tendríamos que revisarlo…”. Pensé, (“desde luego, han pasado dos años y al menos hay que incrementarle el IPC”). Continuó: pues hoy en día las cosas no son como antes y bla, bla, bla…

Como mi situación era complicada decidí aceptar un generoso descuento, “solo cobraría 1 cabra, las gallinas y el cuerno de alce, que les den a los coño buitres leonados…”, y me puse manos a la obra, de lo malo, malo, al menos, aprendería muchas cosas sobre su negocio, ya tendría tiempo de ganar mucho dinero cuando me convirtiera en un buen profesional…, aprovecharía para aplicar alguna nueva tecnología con la que poder sacar mayor valor añadido al software desarrollado y con suerte quizás, podría venderlo a otras tribus de la zona.

Esa misma semana me comunica que las reuniones periódicas semanales no iban a poder ser realizadas los lunes, ya que, debido a sus logros en la gestión de la aldea le han hecho jefe de la tribu y tiene que dedicar todo su tiempo productivo a fabricar herramientas, palitos para “pescar” hormigas, tiras de corteza para cazar termitas, martillos para cascar nueces, ramitas para espantar moscas, etc. y que además el sábado tiene que ir al consejo tribal, así que solo podría reunirse conmigo el domingo por la mañana, pues por la tarde tenia la fiesta “canival…”.

Como ya había dedicado mucho tiempo al proyecto y debido a mi complicada situación económica, decido aceptar y reunirme con él todos los domingos por la mañana para tratar de conocer en detalle los procesos más complejos de su negocio, después de un par de sesiones domingueras en las que sólo me explica cómo ha llegado a convertirse en un “Empresario de éxito”, me llama diciendo: “A partir de ahora no voy a poder atenderte, así que mejor trata de todos estos asuntos sin importancia con mi secretaria”, “¡Dios! que alivio”, por fin voy a tratar con alguien que al menos tiene graduado escolar… y además usa minifaldas…. si, si, en la aldea del tipo este, todas las secretarias iban con minifaldas y enseñando… bueno mejor me callo, una de sus frases decía: “hay que saber sacar verdadero partido de los recursos de los que disponemos…”

Después de un par de reuniones con su secretaria, ésta me comenta que el tal Australopithecus, tiene un tinglado montado de miedo, no paga a nadie, ella lleva seis meses y tan sólo ha cobrado el primero y el tío se acaba de comprar una balsa supermirafiori para navegar por el río y visitar a una novia que tiene en la tribu ubicada 10 millas más arriba y que además no rema, que le duele mucho la espalda y que tiene que venir tarzan con la chita y el elefante para remontarle por el río. El sujeto intenta cada poco tiempo hacer la vida imposible a sus empleados para que muchos se tengan que ir, renunciando incluso a la indemnización y que el “informático” que había estado antes que yo, lo había dejado porque llevaba más de un año trabajando y no le había pagado nada, que únicamente le había contratado porque exigía 2 buitres leonados menos que yo.

Ante la situación, decido paralizar al proyecto hasta no cobrar al menos el trabajo realizado, cuando hablo con él para comentarle la situación, le empieza a salir espuma por la boca, los ojos se le hinchan y enrojecen y los colmillos le crecen 4 cm, tembloroso le digo que tiene que asumir la deuda del trabajo realizado, que no estoy dispuesto a continuar hasta haber cobrado al menos un par de gallinas y el putísimo cuerno de alce que por supuesto ya formaban parte de mis deudas, responde que no está dispuesto a pagarme nada, ya que no ha recibido nada a cambio, es más, que si alguien debe algo, ese soy yo, ya que me ha dedicado gran parte de su valioso tiempo y claro, este, era muchísimo más costoso que el mío, ante la peligrosa situación que se fue agravando poco a poco, decido irme y darle un poco de tiempo para pensar con tranquilidad.

Al cabo de unos meses y viendo que las gallinas y el cuerno de alce seguían sin aparecer, decido armarme de valor y acercarme un domingo por la mañana a la choza, a ver si podíamos solucionar la situación de alguna forma, cuando llegó al lugar, aparece una mujer, le preguntó por el sujeto y me dice que ella es su mujer y que este se ha fugado a la tribu del río de arriba dejándola con sus dos hijos, que se ha llevado las dos vacas que tenían, para entregárselas al Jefe de la otra tribu y hacerse con los servicios de un par de mujeres y que ha les ha dejado sus deudas y otros problemas, me enseña lo que queda del negocio, los empleados hartos ya de la situación, habían arramplado con todo y no habían dejado títere con cabeza, incluso la habían amenazado si no aparecía pronto….

No penséis que esta fue la única vez que me han pasado situaciones similares, de hecho yo pensaba que jamás me podría pasar algo parecido, pues este sólo fue el comienzo de varios casos que me ocurrieron posteriormente. Así que he decidió redactar un pequeño manual para que podáis detectar este tipo de homínidos tan perjudiciales para el hombre:

1 – El Australopithecus suele comerciar con cuerno de alce, no entiendo como lo hacen, el alce es mucho más inteligente que el Australopithecus …

2 – Suele despreciar a los sujetos de su misma especie, incluso a sus empleados y familiares cercanos, ten cuidado, lo mismo hará contigo.

3 – Se siente el más listo del mundo, es el único que sabe hacer fuego, los que le rodean no tienen ni puta idea de nada, ellos son los mejores.

4 – Si oyes frases similares, ¡cuidado!, se trata de la especie más peligrosa:

  • Me he hecho a mí mismo…
  • Cuando me fuí de la cueva sólo me lleve lo puesto.
  • En mis tiempos cazaba los leones a mordiscos…
  • No tengo una empresa, tengo un grupo empresarial…. (El equivalente a una Choza y 4 pringaos distribuidos por la peninsula que no cobran hace 6 meses)
  • El nombre de su tribu comienza por “Asociación de ….”
  • Nosotros somos pioneros en….
  • El dinero no es importante, yo me fuí sin nada y mira en lo que me he convertido…
  • He construido yo solito este imperio…
  • Tienes que entender que ésta, no es una empresa cualquiera…
  • Yo invente la rueda…
  • Tu, no estás aquí para pensar…
  • Si a un trabajador no le da tiempo a terminar su trabajo, es su deber continuar hasta finalizarlo…
  • La formación no sirve de nada con estos mendrugos…, eso es para intelectuales…
  • Si quieren estudiar que lo hagan en casa, que yo les pago por trabajar…

5 – Los gestos son fundamentales, a veces, echan espuma por la boca, acostumbran a gritar de forma habitual y si continuas sin entenderlos te atizan un garrotazo.

6 – Si sacan fajos de billetes y te dicen: ¿cuánto necesitas?, cógelos rápido, suele ser un truco muy habitual. Los sacan y los introducen de nuevo en la billetera a la velocidad del rayo. Pero a ti te queda el mensaje subliminal, cuando te vas solo ves los billetes que te debe…

7 – Si quedan contigo el domingo, mucho cuidado, es de los que no van a misa…, acostumbran a ir de caza ese día.

8 – Si se compra una balsa supermirafiori, mucho ojo!!!, estás sólo se otorgan a los homínidos más peligrosos que militan en algún partido político.

9 – Hay una prueba que nunca falla, cuando habléis con él, decir la palabra “gratis”, si sus ojos empiezan a dar bandazos de un lado a otro y aparecen dólares en la cornea como a tío Gilito, es uno de ellos.

10 – Cuando le visitas suele hacerte esperar, tranquilo, está ocupado con otras cosas mucho más importantes que ni con 20000 años de evolución llegaríamos a entender.

11 – No le dan ninguna importancia al dinero, total ellos disponen de todo el necesario.

12 – Sus empleados los “adoran”.

13 – Son muy difíciles de reconocer, ahora se depilan con laser y algunos no se parecen a las fotos de carnet de la parte superior.

14 – Si te invita a la fiesta “canival” y te dice que vas a ser el protagonista, ¡ojito!…

Si tenéis la suerte de tropezaros con algún espécimen de este tipo, recordar, nosotros, los simples mortales estamos en este mundo para ayudarlos, nuestro trabajo y sacrificio no tienen ningún valor, con esta especie podemos aprender a hacer de todo, he visto informáticos que lo mismo instalan una centralita de teléfono, te hacen una paella valenciana o cazan un búfalo con arco y flechas, si no podéis ganar dinero y vuestros hijos tienen que ponerse a trabajar, pues nada, que dejen los estudios y se pongan, total estudiar no tiene ningún sentido, con garrote, mano dura y sin tener ni puta idea de informática se podrán ganar mucho mejor la vida tal y como demuestra esta especie.

Un último consejo, nunca comiences a trabajar bajo ningún concepto si al menos no te hace entrega de un pequeño porcentaje del coste del proyecto, 4 gallinas o una cabra suelen ser suficientes.

Y recordar llevar siempre el garrote a mano, podéis acabar así:

image

Recursividad con Sql Server

Una función muy interesante de Sql Server es la de poder seleccionar un conjunto de datos de forma recursiva de manera que podemos obtener una serie en estructura de arbol.

Partimos de una tabla que tiene dos campos, llamados clave y padre, el campo clave se relaciona con el padre para formar la estructura en arbol.

El siguiente procedimiento almacenado muestra un ejemplo de como conseguir esto:

ALTER PROCEDURE [dbo].[Usuarios_seguridad_seleccionar]
AS
BEGIN    
    DECLARE @minClave int
    SELECT @minClave = MIN(Clave) FROM dbo.Usuarios_seguridad;
    
    WITH UsuariosAccesos AS
    (
        SELECT top 1 us1.Padre,us1.Clave,us1.Variable,us1.Modulo,us1.Contenido,us1.Acceso,us1.Imagen 
        FROM dbo.Usuarios_seguridad us1 
        WHERE us1.Clave = @minClave
        UNION ALL
        SELECT top 100 percent us2.Padre,us2.Clave,us2.Variable,us2.Modulo,us2.Contenido,us2.Acceso,us2.Imagen 
        FROM dbo.Usuarios_seguridad us2 
        INNER JOIN UsuariosAccesos AS us3 ON us3.Clave = us2.Padre  
        WHERE us2.Clave <> @minClave 
    )
 
    SELECT TOP 100 PERCENT ia.Padre,ia.Clave,ia.Variable,ia.Modulo,ia.Contenido,ia.Acceso,ia.Imagen 
    FROM UsuariosAccesos ia
    ORDER BY padre, clave
END
GO
 
La clausula with debe contener un miembro delimitador, en este caso el formado por la  primera sentencia Sql que hace referencia al valor mínimo (Primer nodo) y el segundo miembro recursivo que hace referencia a la misma tabla definida el la clausula With.
El procedimiento almacenado calcula el valor mínimo del nodo con la clave mas baja, posteriormente va leyendo cada nodo relacionado de forma recursiva ya que en el inner join se relaciona con el conjunto de datos definido en la clausula WiTH, finalmente devuelve el conjunto de datos en un orden determinado, el resultado obtenido es el siguiente:

image

La consulta retorna los datos de forma similar a la estructura de arbol que posteriormente se carga en el tree.

image

Para cargar los datos en el control, podiamos haberlo hecho sin recurrir a la recursividad en Sql Server y hacerlo directamente con el lenguaje de programación en el cliente, pero hay veces que puede ser mas interesante recurrir al servidor en lugar de hacerlo en el cliente, por ejemplo para buscar un dato determinado aprovechando las ventajas de las busquedas en el servidor y devolver su nodo, borrar todos los nodos relacionados o simplemente por descargar la tarea del lado del cliente.

Si quereis mas información sobre la clausula WITH que permite realizar este tipo de consultas podeis encontrala en http://msdn.microsoft.com/en-us/library/ms175972.aspx (Ingles) o http://technet.microsoft.com/es-es/library/ms175972(SQL.90).aspx (Español).

Calidad de código

La calidad de software engloba muchos y diferentes aspectos sobre el desarrollo de aplicaciones, que pasan desde la elección de una buena arquitectura, hasta utilización de diferentes herramientas, la aplicación de diferentes técnicas y metodologías de trabajo. Creo que todavía hoy en día, existe mucha gente reticente a apostar por la calidad de código, debido a que piensan que su coste es mayor que su beneficio.

Cuando empecé a trabajar en equipo, surgieron una serie de problemas de difícil solución, en seguida me di cuenta de que los programadores escribimos código de forma muy diferente que realiza las mismas cosas, generalmente algunos, los más experimentados solían redactar un código mas legible, mejor documentado, necesitaban menos líneas para llegar a la misma solución, ya que sus conocimientos eran mayores, esto originaba muchos problemas cuando tenian que modificar o entender el código de los demás y es aquí cuando empecé a interesarme por las reglas de estilo, fxcop y otras herramientas que de alguna forma nos permitían establecer reglas para que todos pudiéramos por decirlo del alguna forma “entendernos mejor”. Por otra parte en la depuración de las aplicaciones observe que era mucho menos costoso detectar y corregir un error en una fase temprana que hacerlo posteriormente.

Para poder entender mejor el trabajo de los otros programadores comenzamos a aplicar algunas de estas reglas, desde normas de estilo, documentación, desarrollo de pruebas unitarias, aplicación de patrones de diseño, normativas de base de datos y un largo etc. Esto empezó a facilitarnos la compresión y la modificación de programas, en poco tiempo empezamos a tener una visión muy diferente del proyecto, nos aporto más claridad y conocimiento del trabajo de los demás y nos ayudo a detectar gran parte de errores en una fase temprana del desarrollo.

Algunos de los beneficios más importantes que observo son los siguientes:

– La aplicación de patrones de diseño suponen la solución más adecuada para resolver un problema determinado. Esta ha sido elaborada y seleccionada en base al entendimiento y posibles soluciones propuestas y analizadas por mucha gente.

– La adopción de herramientas como fxcop, stylecop, resharper, coderush, refactor y otras, permiten minimizar algunos errores en la fase de desarrollo además de obligar a cumplir ciertas reglas de calidad y estilo, que de no utilizar, provocan si el desarrollador no es un experto, a cometer errores de difícil detección como fugas de memoria, aprovechamiento óptimo de los recursos, localización de código no utilizado, y un largo etc. Por otra parte si todos las adoptan nos habituamos a escribir código de una manera similar, con lo que nos será más fácil comprender el trabajo de los demás. De la información de los errores que nos proporcionan aprendemos a programar mejor, liberando y utilizando recursos adecuadamente, con lo que nuestro conocimiento aumenta. Algunas de estas herramientas cuentan con utilidades para ayudarnos a escribir el código y refactorizar de una forma mucho más rápida.

– El uso de profiles nos permite detectar cuellos de botella y otros problemas que de otra forma serian prácticamente imposible de conocer.

– La utilización de pruebas unitarias y otras técnicas de testeo, nos permiten detectar errores en una fase temprana, si no lo hacemos a tiempo a veces puede implicar que tengamos que modificar más de un módulo relacionado con este, con lo que el coste se incrementa aún más. Como dice la frase, “más vale prevenir que curar”.La ventaja de contar con pruebas unitarias de un módulo que no hemos desarrollado nosotros nos permite entender mejor el comportamiento del programa. La aplicación es más fácil de modificar ya que si alguien altera el programa, por ejemplo cambiando el nombre de un campo de un procedimiento almacenado o alterando alguna función como el cálculo de totales de una factura, detectaríamos el error mucho antes de ponerlo en producción evitando mayores consecuencias.

– Se disminuye la dependencia del equipo de desarrollo: Si el día mañana alguno de los desarrolladores no está o la empresa de desarrollo cierra, será mucho más fácil encontrar a alguien que entienda el código que cumple unas determinadas reglas. Si cada miembro del equipo escribe software de forma diferente esto se hace practicamente imposible. Si otra persona o empresa externa cumple nuestros requisitos de calidad esto permite que pueda comprender y extender la aplicación más fácilmente.

La calidad de código no es opcional, de no aplicarla el coste de nuestros proyectos con seguridad será mayor.

Pero no todo es de color de rosa, utilizar estas herramientas requiere tiempo, formación y sobre todo constancia. Realizar pruebas unitarias además de ser costoso requiere mucha disciplina y un alto nivel de desarrollo, no solamente debemos preocuparnos de tener la máxima cobertura en nuestro código, si no que debemos intentar probar todos los extremos, valores nulos y otros factores que de no realizarse disminuyen los beneficios de estas. De igual forma aprender a utilizar profiles y otras herramientas llevan mucho tiempo en formación y desde luego tienen su coste. No debemos obsesionarnos con realizar pruebas unitarias y cumplir con el 85 % de cobertura en todo nuestro proyecto o cumplir a raja tabla todas las reglas que propone fxcop, resharper, coderush, utilizar reglas de estilo, realizar pruebas de carga, utilizar mock objects para crear independencia con nuestro entorno de datos, utilizar profiles para analizar hasta la más mínima señal de que algo va mal, etc, debemos comenzar poco a poco implantando alguna y habituarnos a utilizarla. Si haceís esto y dedicais un poco de tiempo en aprender a sacarles partido, os puedo asegurar que la mayoría se harán indispensables en vuestro trabajo.

Recuerdo que la primera vez que pusimos en marcha fxcopy en uno de los proyectos aparecieron miles de warnings, os aseguro que fue un autentico coñazo eliminarlos, ya que lo aplicamos en una fase media del desarrollo, nos costó bastante tiempo poner la aplicación en orden, pero aprendimos un motón de cosas sobre programación, algunas que nunca hubiéramos conocido si no llega a ser por este tipo de herramientas. Ahora no podemos vivir sin él y cuando vemos una aplicación que no lo utiliza en seguida nos damos cuenta de los errores que se cometen.

Las ventajas de desarrollar código de calidad son innumerables, se facilita la detección precoz de errores y nos permite anticiparnos y corregirlos antes de poner el sistema en producción evitando tener que rehacer gran parte de las aplicaciones. Estas herramientas nacen con el objetivo de permitirnos mejorar en nuestros desarrollos, no quiere decir que nuestra aplicación vaya a estar libre de fallos, pero si que será mejor, que aprovechara mejor los recursos y por supuesto, que tendrá menos errores, tendremos mayor seguridad a la hora de modificar un programa y reglas de trabajo en equipo que de otra forma serian muy difíciles de controla, se facilita la escritura de código y la detección visual de errores en tiempo de diseño, ahorrando mucho tiempo a la hora de programar y depurar la aplicación.

El esfuerzo que debemos realizar para desarrollar código de calidad es grande, pero marcara la diferencia y en poco tiempo nos permitirá recuperar la inversión con creces, así que animaros, merecerá la pena.

Acelera Visual Studio con Discos Solidos (SSD) y Tarjetas de Memoria

Después de leer varios artículos sobre los últimos modelos de discos SSD, y con el fin de acelerar mi trabajo con Visual Studio decidí adquirir un disco SSD modelo OCZ Core Series V2 SATA II 2.5″ SSD con 120 Gb,  las comparativas con los últimos modelos presentados por Intel X25, decían que incluso iban por delante en cuanto a rendimiento, su coste bastante inferior, de unos 340 € frente a los 650 € de un Intel.

 

Core_v2_back_b

La primera impresión cuando lo tienes en las manos es lo poco que pesa, parece un trozo de plástico. Después de clonar el equipo e instalar el disco duro, el rendimiento no parece mejorar, es mas en algunas operaciones incluso parece más lento, consultando en los foros del fabricante, leo que hay que hacer varios ajustes relativos al cache, el servicio de indexado, desfragmentación y otros. Para los interesados dejo los ajustes aquí http://www.ocztechnologyforum.com/forum/showthread.php?t=47212, que supongo haya que realizar en todos los discos SSD. Me pregunto si algunos serán correctos, no lo tengo muy claro.

Lo curioso es que después de hacerlo las búsquedas de archivos son espectaculares, sin embargo el rendimiento general aparentemente sigue siendo muy bajo, los tiempos de compilación con Visual Studio son similares a la utilización de un disco SATA de 7200 rpm, incluso en algunos casos más altos, los test de disco me decían que el rendimiento en lecturas secuenciales era espectacular, en cambio en lecturas aleatorias dejaba mucho que desear, la gran ventaja de la utilización de este disco es que la batería del portátil a pasado a durar más del doble, de dos horas a casi 5, sigo haciendo cambios en la configuración a través de regedit, pues el fabricante ni siquiera ofrece un programa de configuración, el disco tiene una conexión USB para actualizar el firmware, pero este brilla por su ausencia, lo curioso es que antes de comprarlo estuve leyendo en varios post, que los resultados obtenidos con este tipo de discos pasaban por un aumento de rendimiento en torno a un 30 % frente a un disco SATA Normal, en resumen toda una decepción, espero que con alguna actualización y soporte de Windows 7 para discos SSD el rendimiento pueda mejorar, pero no lo tengo nada claro.

Quizás, para trabajar con herramientas de diseño grafico como autocad que maneja archivos grandes el rendimiento mejore, pero en mi caso con Visual Studio me temo que con la cantidad de archivos que tiene la solución y el tamaño de estos que normalmente no supera 20 Kb no sea así. Lo cierto es que estoy bastante decepcionado con este disco, esperaba al menos cierta mejoria en el rendimiento tal y como se comentaba en los artículos.

Por otra parte acabo de renovar mi antiguo PC, un AMD con doble núcleo de los primeros que salieron al mercado, 4 Gb de Ram y un disco serial ata de 250 Gb, adquirí un equipo DELL Optiplex 960 con un procesador Intel Quad Core, 8 Gb de Ram, Vista 64 y un disco SSD de 64 Gb de la marca Samsung.

samsung_ssd_001

Como sabéis Visual Studio no permite realizar cambios en tiempo de ejecución cuando estas depurando en 64 bits, no entiendo porque ni despues del Sp1 han incoporado esta característica que es verdaderamente importante. Como trataba de potenciar el rendimiento decidi renunciar a esta opción.

Con esta configuración los resultados son espectaculares, se reduce el tiempo de compilación en un 70 %, el equipo abre outlook en decimas de segundo, realmente espectacular, el disco utilizado tiene la mitad de capacidad que el primero, pero en rendimiento nada que ver, impresionante, hay que tener en cuenta de que el procesador tambien hace su trabajo en el proceso de compilación los cuatro procesadores no bajan del 60 % de rendimiento, el sistema operativo es de 64 bits, el uso de memoria no sobrepasa los 4 gygas. Resharper y Devexpress van como un tiro. Es increíble que en un equipo que ronda los 1200 €, el rendimiento haya mejorado tanto, la verdad merece la pena la inversión.

Aprovechando este post, he realizado otra prueba utilizando una tarjeta de memoria de 4 Gb, similar a esta http://www.gigabyte.com.tw/Products/Storage/Products_Overview.aspx?ProductID=2180 Desconozco la marca de la tarjeta que tengo ya que la consiguió un compañero a través de unos proveedores directamente en china, la de la foto es de la marca Gygabyte y es practicamente identica a la mia exceptuando la bateria que es una pila normal recargable de 1,5 V, En España todavía no he visto ningún sitio donde se comercializa.

desktop_productimage_i-ram_1.3_big 

Esta tarjeta te crea un disco virtual de memoria, esta sustentanda por una pequeña batería de litio que se recarga a través del slot PCI, para evitar perder los datos cuando apagamos el equipo, aquí también los resultados son espectaculares, después de dejar el proyecto en el disco de memoria que tiene una capacidad de 4 Gygas, suficiente para almacenar varios proyectos, y redirigir los archivos temporales a un directorio del propio disco, las pruebas son verdaderamente asombrosas, el rendimiento en la compilación es similar al logrado con el nuevo equipo con disco duro SSD. No os puedo poner el precio de esta tarjeta, pero según he leído es cara.

Otra posible solución de bajo coste para acelerar Visual Studio pasa por utilizar memorias Flash como las que se usan en las cámaras réflex digitales de alto rendimiento, abra que ver las especificaciones de lectura(escritura, esta es una de las mas rápidas actualmente..

g_00014498 

Se pueden utilizar como un disco mas en un portatil o se pueden conectar a traves de un interface SATA como el de la foto a cualquier PC, no he realizado las pruebas con este tipo de dispositivos, una memoria de 4 Gb similar a la de la foto no costara mas de 70 €, la de la foto de 8 Gb esta sobre los 110 € y el un interface para pc sobre los 20 €.

adsacf_detail

El ahorro de costes que puede suponer trabajar con este tipo de dispositivos puede ser espectacular, imaginar un equipo de 8 personas que compilen una media de 10 veces al día y el proceso tome unos 4 minutos, supone que podemos ahorrarnos 4 horas diarias solo en la compilación, aunque el dispositivo solo mejorase un 30 % el rendimiento, ya merece la pena realizar la inversión.

Otra solución muy interesante y gratuita para los que dispongais de suficiente memoria, al menos 3 Gygas, puede ser la utilización de este programa gratuito, https://www.cenatek.com llamado RamDiskVe, el programa crea un disco virtual utilizando la memoria ram del equipo, las pruebas que he realizado han logrado mejorar el proceso mas de un 30 %, aunque el rendimiento al guardar el contenido del todo el disco antes de apagar el equipo no es muy bueno y tiene algun problema, de hecho la versión para Windows Vista es beta, pero puede ser una buena alternativa que no nos cuesta nada probar.

En resumen, cuidado al comprar un disco SSD, no todos son iguales… los discos de memoria pueden ser una buena alternativa y si teneís memoria suficiente probar RamDiskVe.

Os dejo un video sobre el samsung SSD, tarda un poco, pero merece la pena. http://www.youtube.com/watch?v=pJMGAdpCLVg

[View:http://www.youtube.com/watch?v=pJMGAdpCLVg:540:0]

Espero que el post os resulte útil.

Diseñando controles. Atributo DesignerSerializationVisibility.

En el siguiente ejemplo hemos encapsulado un texbox dentro de un UserControl y añadido la propiedad MaxLenght para poder modificar la propiedad de control encapsulado.

Public class UserControl1 : UserControl
{
     public UserControl1()
     {
         InitializeComponent();
     }
 
     public int MaxLenght
     {
         get { return textBox1.MaxLength; }
         set
         {
             textBox1.MaxLength = value;
         }
     }
    
     private void InitializeComponent();
     {
         this.textBox1 = new System.Windows.Forms.TextBox();
         this.SuspendLayout();
         // 
         // textBox1
         // 
         this.textBox1.Location = new System.Drawing.Point(3, 3);
         this.textBox1.Name = "textBox1";
         this.textBox1.Size = new System.Drawing.Size(100, 20);
         this.textBox1.TabIndex = 0;
         // 
         // UserControl1
         // 
         this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
         this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
         this.Controls.Add(this.textBox1);
         this.Name = "UserControl1";
         this.Size = new System.Drawing.Size(108, 27);
         this.ResumeLayout(false);
         this.PerformLayout();
 
     }
 
     private System.Windows.Forms.TextBox textBox1;
}

Si arrastramos el control al formulario, observamos que en el código del InitialiceComponent del form aparece la siguiente linea:

this.userControl11.MaxLenght = 32767;

El generador de código ha añadido la propiedad con el valor por defecto en el InitializeComponent del formulario.

A partir de aqui solo se podra alterar el valor de la propiedad dentro del propio formulario, alterando manualmente su valor, esto obligaría a recorrer todos los formularios donde se usa el control.

El verdadero problema es que hagamos lo que hagamos en nuestro control el valor de la linea del InitializeComponent no cambiará ya que esta se introduce solo la primera vez que arrastramos el control al formulario. Con lo que el valor del Maxlengt en el formulario siempre sera 32767.

Si lo que buscamos es poder establecer a todos los controles una propiedad publica y un valor inicial, deberemos decirle a la propiedad que no se agrege a los contenedores donde se utilize el control. Esto se consigue decorando la propiedad con el atributo DesignerSerializationVisibility.

[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public int MaxLenght
{
    get { return textBox1.MaxLength; }
    set
    {
        textBox1.MaxLength = value;
    }
}

 

El atributo utilizado tiene tres valores posibles:

– Hidden. El generador de código no produce código para el objeto

– Visible. El generador de código produce código para el objeto

– Content. El generador de código produce código para el contenido del objeto más que para el objeto en sí.

De esta forma la linea del InitializeComponent no se introducira en el formulario, si alteramos el valor de la propiedad en el control, su valor se utilizará en todos los contenedores donde le utilicemos excepto en aquellos en que explicitamente cambiemos su valor.

Si establecemos la propiedad sin atributos debemos tener en cuenta que por cada propiedad se añadira al menos una linea en todos los sitios donde utilizemos el control, esto además de penalizar el rendimiento, porque el valor ha de ser cargado cada vez que abrimos el formulario, elimina la posibilidad de realizar cambios en el control y propagarlos a todos los sitios donde se utilize.

En el caso de una propiedad formada por un array inicializado con valores, el problema es mucho mayor, ya que podemos encontrarnos en nuestro formularios casos como este:

private void InitializeComponent();
{
 
       this.userControl13.Array = new string[] {
        "0",
        "1",
        "2",
        "3",
        "4",
        "5",
        "6",
        "7",
        "8",
        "9",
        "10",
        "11",
        "12",
        "13",
        "14",
        "15",
        "16",
        "17",
        "18",
        "19",
        "20",
        "21",
        "22",
        "23",
        "24",
        "25",
        "26",
        "27",
        "28",
        "29",
        "30",
        "31",
        "32",
        "33",
        "34",
        "35",
        "36",
        "37",
        "38",
        "39",
        "40",
        "41",
        "42",
        "43",
        "44",
        "45",
        "46",
        "47",
        "48",
        "49",
        
};
 
this.userControl13.Location = new System.Drawing.Point(30, 80);
this.userControl13.Name = "userControl13";
this.userControl13.Size = new System.Drawing.Size(108, 27);
this.userControl13.TabIndex = 2;

Es muy importante entender como funciona el generador de código de visual studio para decorar las propiedades de controles y formularios que vayan a ser reutilizados de forma adecuada evitando sobrecargar sus contenedores y aprovechar las ventajas de la herencia.