So Long, and Thanks for All the Fish!

En este articulo doy por cerrada una etapa de alta dedicación al Blog. Luego de cuatro meses con por lo menos un articulo por día, decidí tomarme esto con mayor tranquilidad, sin la obsesiva necesidad de escribir tanto.

Voy a seguir escribiendo artículos, voy a seguir leyendo libros, y obviamente voy a seguir trabajando en el apasionante mundo de la ingeniería de software.

Esto recien es el comienzo!

Facts and Fallacies of Software Engineering

Facts and Fallacies of Software Engineering es un reciente (2002) libro de Robert Glass donde enuncia 55 hechos y 10 falacias de la ingeniería de software, cuidadosamente indicando las fuentes de cada uno de ellos y antes presentando una discusión y controversias sobre el tema.

Es un libro muy valioso, porque realmente te abre la cabeza. Hay pocas verdades que pueden llegar a sorprender a cualquier persona que esta en el mundo del software hacer rato, es mas, hay verdades que pueden herir a mas de uno. Yo no estuve muy de acuerdo con varias de ellas. Lo mejor fue que muchas me sorprendieron gratamente, entre ellas verdades sobre el mantenimiento de las cuales escribí ayer.

El objetivo de este libro es hacer pensar a la gente, presentar estos hechos para que se pueda discutir y actuar sobre ellos para progresar. Lo considero esencial para cualquier practicante de la ingeniería del software.

Les dejo los hechos resumidos en una oración que obtuve del Blog Coding Horror:

People

1. The most important factor in software work is the quality of the programmers.
2. The best programmers are up to 28 times better than the worst programmers.
3. Adding people to a late project makes it later.
4. The working environment has a profound impact on productivity and quality.

Tools and Techniques

5. Hype (about tools and technology) is a plague on the house of software.
6. New tools and techniques cause an initial loss of productivity / quality.
7. Software developers talk a lot about tools, but seldom use them.

Estimation

8. One of the two most common causes of runaway projects is poor estimation.
9. Software estimation usually occurs at the wrong time.
10. Software estimation is usually done by the wrong people.
11. Software estimates are rarely corrected as the project proceeds.
12. It is not surprising that software estimates are bad. But we live and die by them anyway!
13. There is a disconnect between software management and their programmers.
14. The answer to a feasability study is almost always "yes".

Reuse

15. Reuse-in-the-small is a solved problem.
16. Reuse-in-the-large remains a mostly unsolved problem.
17. Reuse-in-the-large works best in families of related systems.
18. Reuseable components are three times as hard to build and should be tried out in three different settings.
19. Modification of reused code is particularly error-prone.
20. Design pattern reuse is one solution to the problems of code reuse.

Requirements

23. One of the two most common causes of runaway projects is unstable requirements.
24. Requirements errors are the most expensive to fix during production.
25. Missing requirements are the hardest requirements errors to correct.

Design

26. Explicit requirements 'explode' as implicit requirements for a solution evolve.
27. There is seldom one best design solution to a software problem.
28. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.

Coding

29. Designer 'primitives' rarely match programmer 'primitives'.
30. COBOL is a very bad language, but all the others are so much worse.

Error removal

31. Error removal is the most time-consuming phase of the lifecycle.

Testing

32. Software is usually tested at best to the 55 to 60 percent coverage level.
33. 100 percent test coverage is still far from enough.
34. Test tools are essential, but rarely used.
35. Test automation rarely is. Most testing activities cannot be automated.
36. Programmer-created, built-in debug code is an important supplement to testing tools.

Reviews and Inspections

37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
38. Rigorous inspections should not replace testing.
39. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
40. Reviews are both technical and sociological, and both factors must be accommodated.

Maintenance

41. Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.
42. Enhancements represent roughly 60 percent of maintenance costs.
43. Maintenance is a solution-- not a problem.
44. Understanding the existing product is the most difficult maintenance task.
45. Better methods lead to more maintenance, not less.

Quality

46. Quality is a collection of attributes.
47. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.

Reliability

48. There are errors that most programmers tend to make.
49. Errors tend to cluster.
50. There is no single best approach to software error removal.
51. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.

Efficiency

52. Efficiency stems more from good design than good coding.
53. High-order language code can be about 90 percent as efficient as comparable assembler code.
54. There are tradeoffs between optimizing for time and optimizing for space.

Research

55. Many researchers advocate rather than investigate.

Para cerrar el artículo de hoy les dejo las 10 falacias:

1. You can't manage what you can't measure.
2. You can manage quality into a software product.
3. Programming can and should be egoless.
4. Tools and techniques: one size fits all.
5. Software needs more methodologies.
6. To estimate cost and schedule, first estimate lines of code.
7. Random test input is a good way to optimize testing.
8. "Given enough eyeballs, all bugs are shallow".
9. The way to preduct future maintenance costs and to make product replacement decisions is to look at past cost data.
10. You teach people how to program by showing them how to write programs.

No hay que desmerecer a los proyectos de mantenimiento

Estoy leyendo un libro titulado "Facts and Fallacies of Software Engineering" de Robert Glass y encontré unos hechos o "facts" sobre el mantenimiento en la ingeniería de software que me parecieron interesantes y compartí con el equipo del proyecto en cual trabajo (Que se trata sobre mantenimiento de varias aplicaciones) y tambien quiero compartir aca.

En este libro el autor presenta hechos y falacias, luego discute, luego cuenta las controversias alrededor del mismo y finalmente cita las fuentes.

Maintenance typically consumes 40 to 80 percent (average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.

Corolario: Old hardware becomes obsolete; old software goes into production every night.

Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.

The 60/60 rule: 60 percent of software's dollar is spent on maintenance, and 60 percent of that maintenance is enhancement. Enhancing old software is, therefore, a big deal.

Maintenance is a solution, not a problem.

Far too many people see software maintenance as a problem, something to be diminished and perhaps even "obliterated." In saying that, they are really expressing their ignorance. The only way that software maintenance could be a problem would be if nearly all of it were about fixing errors. And we have already seen that it's not. Far from it, in fact. Maintenance, instead, is software's unique solution to the problem "we built this thing, but now we wish we had built something a little different."

In examining the tasks of software development versus software maintenance, most of the tasks are the same-except for the additional maintenance task of "understanding the existing product." This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus it is possible to claim that maintenance is a more difficult task than development.

Maintenance life cycle:

• Defining and understanding the change-15 percent
• Reviewing the documentation for the product-5 percent
• Tracing logic-25 percent
• Implementing the change-20 percent
• Testing and debugging-30 percent
• Updating the documentation-5 percent

Better software engineering development leads to more maintenance, not less.

Systems built using "modern development methods" were more reliable than those built using older ways. They required repair less often. But those systems required more time tomaintain them. How could that be?

These systems took longer to maintain than the others because more modifications were being made to them. And more modifications were being made because it was easier to enhance these better-built systems. Most organizations have a long backlog of enhancements to be made to their software products (Software 1988). The better-built systems were simply making their way through those enhancement queues faster than their more poorly built brethren.

Referencias: Facts and fallacies of software engineering, Robert Glass, 2002

Historial de versiones en una página Wiki de Trac

En este articulo voy a dejarles el simple código para armar una tabla con el historial de versiones en una página del wiki de Trac (Trac un software de administración de proyectos web que recomendé anteriormente).

Historial de versiones en una página de Trac

Siempre es recomendable mantener información de versiones en los wikis para ver rápidamente quien agrego que cosa, aunque también esta información esta accesible viendo la historia de este wiki (ya que Trac trabaja con control de versiones sobre los wikis).

Les dejo el código para que ingresen sobre todas sus paginas wikis en Trac. Para agregar una nueva linea, simplemente hay que copiar la ultima y cambiarle los datos.

===== Revision History =====
||Version||Date ||Author||Notes||
||1.0 ||2006.08.17||John||First draft||
||1.1 ||2006.08.31||Jane||Added this and that||

-----

Matemática... ¿Estás ahí?

Realmente me cuestan las matemáticas. No es algo que oculte. Debido a que me cuestan, siento rechazo por ellas. Es común sentir miedo o emociones negativas a algo que desconoce o que le cuesta. Igual siempre le vi un atractivo a ellas y este libro me ayudo a encontrarles un lado muy interesante.

En este libro, Adrián Paenza, quien es licenciado, doctor en matemática, y periodista, pretende contarle al lector sobre diferentes temas atrapantes de la matemática, dando a conocer distintos problemas de cierto interés y contándole al lector sobre diferentes propiedades y teorías pertenecientes a la matemática que podrían ser calificadas como divertidas; y declara que pensar puede ser algo entretenido. Como se señala en el resumen del libro, entre estos conceptos, problemas y demás relacionados con la matemática, Paenza le habla al lector de temas tan diversos como de los diferentes tipos de infinitos, de los números primos, la división por cero, las apuestas y las probabilidades, etcétera.

Hay tres libros en la serie. Hasta ahora leí los primeros dos, tengo que comenzar a leer el ultimo. Por suerte todos los libros están disponibles para bajarse gratuita y legalmente para uso personal. Les dejo los links:

Matemática... ¿Estás ahí?
Matemática... ¿Estás ahí?: Episodio 2
Matemática... ¿Estás ahí?: Episodio 3,14

When you ASSUME you make an ASS out of U and ME

Olvidándonos de la frase que titula a este articulo, todos los días hacemos asunciones, ya que son una parte natural y lógica del proceso de toma de decisiones. El problema se encuentra en:

1. Hacer asunciones en vez de tomar decisiones precipitadas: Cuando no puedo investigar algún tema tengo que tomar una asunción. Si puedo encontrar información fácilmente, demuestra que no hice mis deberes y tome una decisión precipitada.
   
2. Comunicar las asunciones al equipo: El equipo va a poder detectar errores!
3. Realizar seguimiento de las asunciones: El equipo va monitorear las asunciones que les comunicaste y va a saber cuando consultarte para revisar una decisión que tomaste cuando surge un problema
   

Para mas sobre este tema, les recomiendo que lean: Real World Decisions III: Making assumptions and jumping to conclusions

The Five Temptations of a CEO: A Leadership Fable

Este libro de Patrick Lencioni esta escrito en forma de fabula. Cuenta como un CEO de una empresa que tiene la reunión anual con los accionistas de la empresa al día siguiente se encuentra con unos extraños personajes en el tren, que le comentan las cinco tentaciones en las que puede caer un CEO. Realmente es un libro muy entretenido que te deja reflexionando sobre la forma en que uno actúa ante ciertas situaciones en la vida laboral (sea o no sea uno un CEO). Les dejo las cinco tentaciones de una crítica al libro, aunque igual les recomiendo que lo consigan y lo lean ya que van a poder entender cada una de ellas mucho mejor.

1. Soft-pedaling your drive to achieve results, tending instead to avoid making decisions that might damage your ego or reputation;

2. Wanting to be liked by peers and direct reports (It is lonely at the top, isn't it?), therefore shying away from holding them accountable;

3. Hesitating to take decisive action, (and/or hold direct reports accountable), until more information is in hand. In a world of imperfect and ever-shifting information, the CEO can project vague and hesitant direction to his/her reports, at the risk of paralysis;

4. Restricting "productive ideological conflict" among the management team during decision-making, a temptation motivated by a desire for harmony and/or a fear of conflict; and,

5. Overtly or unconsciously portraying himself/herself as invulnerable, discouraging direct reports from challenging his/her ideas, in turn preventing the foundation of trust that can steady an organization through hard times.

Gracias Ivo por la recomendación!

Las leyes de Murphy generales y para IT (Murphy's Laws of Information Technology)

Las famosas e infames leyes de Murphy son conocidas por todo el mundo. Se aplican a todas las disciplinas humanas, pero estoy seguro que al software le afecta mas de lo común, debido a la juventud de esta actividad. Les dejo las principales leyes de Murphy:

• Nothing is as easy as it looks.
• Everything takes longer than you think.
• Anything that can go wrong will go wrong.
• If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. Corollary: If there is a worse time for something to go wrong, it will happen then.
• You never run out of things that can go wrong.
• If anything simply cannot go wrong, it will anyway.
• If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop.
• If everything seems to be going well, you have obviously overlooked something.
• It is impossible to make anything foolproof because fools are so ingenious.
• Whenever you set out to do something, something else must be done first.
• Every solution breeds new problems.

Dejando atrás las leyes generales, entremos en las leyes de Murhpy aplicadas a IT, que son las originales extrapoladas a este campo.

Sobre Hardware:

• Law of Inconvenient Malfunction: A device will fail at the least opportune possible moment.
• Law of Cable Compatibility: If you choose a cable and a connector at random, the probability that they are compatible is equal to zero.
• Law of Hardware Compatibility: The probability of a given peripheral being compatible with a PC is inversely proportional to the immediate need for that peripheral.
• Law of Bad Sectors: The probability that an untested diskette will have bad sectors is directly proportional to the importance of the data written onto the diskette.
• First Law of Selective Gravitation: When an object is dropped, it will fall in such a way as to cause the greatest possible damage to itself and/or other objects on which it lands.
• Second Law of Selective Gravitation: The tendency for an object to be dropped is directly proportional to its value.
• Law of Reality Change: Unalterable hardware specifications will change as necessary to maximize frustration for personnel affected by said specifications.
• Law of Noise: Noise bursts occur so as to cause the most, and/or most serious, errors in data communications, regardless of the actual amount of noise present.
• Law of Expectation: Consumer expectations always outpace advances in hardware technology.
• Law of the Titanic: If a device cannot malfunction, it will.

Sobre programación:

• Law of Debugging: The difficulty of debugging software is directly proportional to the number of people who will ultimately use it.
• Law of Neurosis: The chances of software being neurotic (developing bugs spontaneously without apparent reason) is directly proportional to the confusion such neurosis can cause.
• Law of Available Space: If there are n bytes in a crucial software program, the available space for its convenient storage or loading is equal to n-1 bytes.
• First Law of Bad Sectors: The probability of software being mutilated by bad sectors is directly proportional to the value and/or importance of the programs.
• Second Law of Bad Sectors: When a program is mutilated by bad sectors, the damage will occur at the point(s) that result in the most frequent and/or severe errors when the program is run.
• Law of Noise: When a downloaded program is corrupted by noise, the corruption will occur at the point(s) that result in the most frequent and/or severe errors when the program is run.
• Law of Software Compatibility: If two programs are chosen at random, the probability that they are compatible is equal to zero.
• Law of Option Preferences: When two people share a computer, their software option preferences will differ in every possible way.
• Law of Expectation: Consumer expectations always outpace advances in software technology.
• Law of the Titanic: Bug-free software isn't.

Ver Referencia.

No lo van a leer!! (TAGRI)

Continuamos con los principios. Este esta relacionado con la documentación. TAGRI significa They ain't gonna read it. No creo que haya alguien que dude este principio, la documentación no siempre se lee (¿Es gratificante hacer la documentación para usuarios?).

Este concepto se complementa con el que enuncie ayer, YAGNI. La idea de las metodologías ágiles es crear documentación 'ágil' que refleje las necesidades reales de la audiencia de la documentación. La mejor manera de hacerlo es trabajar lo mas cercanamente posible con la gente para la cual uno esta documentando.

Estos son problemas típicos de la documentación en el software:

• Projects with detailed requirements specifications fail and/or to have the development team ignore portions of the specification because they believe they know better.
• Detailed architecture documents be created by a project architect only to have the developers take their own approach anyway, even when the original architecture was pretty darn good.
• Detailed test documents created only to be discarded at the end of the project because the development team has run out of time.
• Documents created put on the shelf and ignored after they passed the documentation review.

La solución se basa en cumplir las siguientes reglas:

• Treat documentation like any other requirement. Any document, even if it's IT related, should be costed, prioritized, and treated like any other system requirement.
• Create documents with a clear audience.
• Work with the true audience to identify their actual needs.
• Write agile documentation: any documentation that you do write should be just good enough for your current situation.
• Single source information: When you single source information you strive to record it in one place and one place only.
  

Les recomiendo que lean la fuente de este articulo, que contiene cuatro anectodas muy interesantes.

YAGNI!

YAGNI, o "You ain't gonna need it" es un termino que fue utilizado por primera vez por la gente que apoya XP (Extreme Programming). Es una practica que argumenta lo siguiente:

"Always implement things when you actually need them, never when you just foresee that you need them."

Este principio consiste en que no se debe nunca agregar funcionalidad excepto que sea necesario. La tentación de escribir código que no es necesario, pero que puede serlo en un futuro tiene desventajas. Estas son las principales razones para respetar el principio\:

• You save time, because you avoid writing code that you turn out not to need.
• Your code is better, because you avoid polluting it with 'guesses' that turn out to be more or less wrong but stick around anyway.

Fuentes: Wikipedia; ExtremeProgrammingRoadmap

El principio KISS

El principio KISS ('keep it simple, stupid') enuncia que la simplicidad en el diseño del software (u otra disciplina) debe ser un objetivo clave y que la complejidad innecesaria debe ser evitada. Este principio es utilizado en las metodologías de desarrollo ágil, ya que el diseño es incremental y se refactoriza el código constantemente, sin tomarse mucho tiempo al principio para tener un arquitectura para toda la aplicación, como se suele hacer en las metodologías de software clásicas.

Esto es algo muy básico, pero hay veces que es olvidado, demasiadas veces. Cuando uno evita por alguna razón u otra la solución mas simple a un problema, se va a encontrar con cuestiones a resolver inesperadas, que generalmente superan en recursos y en tiempo al camino mas simple, y el resultado es el mismo o peor.

Siempre sigan el camino mas simple, las soluciones rebuscadas no ayudan en nada!

Poniéndose el equipo al hombro

Hoy voy a recordar una conversión que tuve con un directivo de la empresa en mi primer trabajo que cambio mi forma de pensar sobre mi rol de líder de proyecto y la forma de afrontar situaciones. Todo surgió por un problema en la paga de un equipo externo que trabajaba en un proyecto de creación de una librería de software.

El tema fue que se les había prometido algo, pero debido a cambios en la empresa (Léase fusión) no pudieron cumplirse. Era un tema de recursos humanos, entonces yo estaba esperando que el encargado de recursos humanos (que se encargaba de la liquidación de sueldos) les comentase sobre el tema.

El equipo había venido a la empresa por una reunión de entrenamiento y querían saber en que estado estaba el cumplimiento de la promesa, y yo sabia que no se iba a cumplir, pero opte por pedir ayuda a la persona de recursos humanos para que venga a hablar con ellos del tema ya que con su experiencia en el área estaría mejor capacitado para manejar ese tipo de situaciones. La cosa es que como eran diez personas, la persona de recursos humanos opto por no ir y resolver el tema luego para evitar problemas (Léase diez personas juntas enojadas por la rotura de la promesa).

Luego tuve la conversión con un directivo de la empresa que me comento que si era mi equipo, yo me tenia que encargar de notificar cualquier cosa, sea tema del proyecto, paga, lo que sea. Realmente esa charla me sirvió, porque yo antes evitaba estos temas y al encargarme pude sentirme mejor con respecto a la gente. Les conté uno por uno como era la situación y sentí un inmenso alivio, ya que no había mas nada que ocultar.

Mi consejo es que sea cual sea el problema, hay que comunicarse siempre, ir con la verdad y ver luego que rumbo seguir. En este caso el tema ya estaba resuelto, no había nada mas para hacer, pero gane mas confianza con el equipo y aunque estaban descontentos en ese aspecto, siguieron trabajando sabiendo que yo había hecho todo lo posible.

Don't Make Me Think: A Common Sense Approach to Web Usability

Uno de los últimos proyectos en los cuales trabaje en mi primer trabajo fue en un desarrollo de un sitio web de "venta" (en realidad leasing) de autos. Era un sitio que mucha gente utilizaría entonces se le prestaba especial atención a cualquier tema que podría parecer mínimo, como la ubicación de las cosas, los colores, etc.

Realmente el cliente tenia muchas buenas sugerencias y yo me ponía mal porque no había pensado en ellas! Entonces decidí buscar algo sobre diseño y usabilidad web y me encontré con este libro de Steve Krug, que es uno de los mas famosos del genero.

Realmente es un libro muy divertido para leer y comienza a explicar como realmente usamos la web (Leer capitulo gratuito del tema) y luego da muchas sugerencias de la forma de organización, navegación y toda la interacción con un usuario en un sitio web.

Estoy muy de acuerdo con el autor en que la gente busca información en la web, estamos todos muy apurados y nos molesta tener que dar datos sin sentido, ni que nos llenen la pagina de fuegos artificiales que no sirven para nada. El autor termina el libro con unos mails genéricos para mandar a los managers para convencerlos de porque eso es malo. Imperdible para cualquier persona que le interese el tema de usabilidad y también diseño web.

Assembla - Accelerating Software Development

Una herramienta web muy popular para albergar proyectos de software gratuitamente es Assembla. También existen versiones comerciales con muchas mas funcionalidades (ver comparacion). Es muy interesante para hacer trabajos prácticos para la facultad.

Estos son algunos de los servicios que provee la versión gratuita:

• Ilimitada cantidad de miembros de un equipo.
• Subversion (Repositorio de hasta 500MB).
• Trac (Tickets y administración de proyectos).
• Wiki.
• Foro de discusiones.
• Alertas por mail, RSS..
• Chat.
• Seguimiento y reporte de tiempos.

Esta herramienta es altamente recomendable para utilizar para hacer cualquier tipo de proyecto de software en equipo.

Llamada inesperada: en la cuerda floja

La segunda vez que salimos a comer afuera en nuestros almuerzos semanales que comente ayer, tuvimos un llamado urgente que lo interrumpió. Nuestro gerentes de ventas estaba en Estados Unidos para lanzar un proyecto que veníamos haciendo, realmente hace muy poco, con pocos recursos y donde los problemas eran muy comunes.

El tema era que la primera versión no funcionaba. Eramos muy jóvenes es esa época, no seguíamos ningún proceso de desarrollo ni teníamos a alguien de QC asignados. La versión la habíamos lanzado el lunes bien tarde y falto aplicarle un Stored Procedure ala base de datos, que impedía que el programa cumpla con la función principal para el cual fue diseñado. Realmente un error trágico.

El líder técnico y yo abandonamos al resto de los comensales, nos pusimos los trajes de bomberos y el casco y fuimos a la empresa a ver que pasaba. Por suerte luego de unos momentos muy tensos, solucionamos el problema, el gerente de ventas se las arreglo para que el cliente no nos cancele el contrato y ese proyecto fue muy exitoso, aprendimos mucho y nos trajo muchas alegrías hasta su cancelación.

Almuerzos semanales con el equipo y otros compañeros de la empresa

A principio del 2006, propuse a mis compañeros de Isla (y a cualquier otra persona que se prendiese) a romper la rutina e ir a comer todas las semanas un día afuera, ya que siempre comíamos en la oficina. Realmente fue una propuesta muy exitosa que realmente disfrute durante mi estadía en mi primer trabajo y en el comienzo del segundo. Así realice la propuesta:

Gente,

Propongo que una vez por semana, podría ser el viernes, salgamos a almorzar todos los de la isla (Puede venir gente de otra isla si quiere). Estaría bueno que cada semana alguien proponga un lugar distinto. Como yo sugerí esto, y además como hace mucho tengo ganas, propongo ir a este viernes al Subway que esta por florida, llegando a plaza de mayo.

Saludos!

Como veran tiene tiempo, ya que el local de Subway fue cerrado. El viernes pasado se fueron de la empresa de mi primer trabajo las ultimas dos personas con las que seguía juntándome ya que mi nuevo trabajo queda muy cerca. Ahora estaremos separados y no nos juntaremos tan seguido. Voy a extrañar mucho nuestras reuniones.

Realmente fue una muy buena idea juntarnos a comer seguido, realmente afianzo al equipo y también a otras personas de la empresa.

Sin comunicación con el cliente: naufragio inminente

En el proyecto mas largo que participé (en mi primer trabajo), en los últimos 9 meses de sus casi 2 años de duración, la comunicación con el cliente era muy escasa, prácticamente inexistente. Realmente era muy raro, ya que llegaban los pagos (muy jugosos de por cierto), nosotros realizábamos las entregas que estaban programadas y no obteníamos nada de feedback.

El proyecto se basaba en la creación de una librería de archivos para ser utilizada en un programa de identificación de software, de "License compliance" o "Software Asset Management". Por lo poco que sabíamos, nuestra librería iba a ser adoptada en una futura versión de ese programa y las pruebas de identificación que habían realizado no eran muy exitosas que digamos.

Corregíamos las pocas cosas que nos decían, y seguíamos trabajando para mejorar el producto, pero en los últimos 9 meses no hubo mucha comunición. Se notaba preocupación en el ambiente, y nos recomendaban que no nos contactemos con el cliente al menos que sea absolutamente necesario, ya que mientras llegase el dinero, los directores estaban tranquilos. No querían que se den cuenta que el proyecto seguía en curso, no querían despertar al monstruo. Igual sabían que tarde o temprano iba a terminar, debido a el poco interés del cliente. Como dice el titulo (el primero de este blog que me sale con rima), si no hay comunicación con el cliente, espera un naufragio inminente.

Pueden leer la historia de la cancelación de ese proyecto acá, y ver el maravilloso equipo que formo parte del proyecto acá.

Features are a one-way street

Hace poco me encontré con este interesante artículo que comentaba sobre una funcionalidad que se había agregado al sitio de Netflix (Es un servicio de alquiler de películas web).

Luego de unas semanas de haber puesto el servicio en producción, lo sacaron porque les parecía ser muy confuso y no le veían valor.

Pero fue demasiado tarde. La gente se enojo. El anuncio del cancelamiento de esta funcionalidad en el blog recibió 1287 comentarios. Netflix cambió de parecer y publico la funcionalidad nuevamente.

La lección es que cuando tenés una gran cantidad de usuarios, no podes sacarles funcionalidades. Sea buena o mala la nueva funcionalidad, una vez que lo lanzaste, es como un contrato con tus usuarios, que si son numerosos, seguro que una buena porción de ellos la utilizara sea o no sea buena.

Lean el comentario de un cliente furioso que cancelo su subscripción a Netflix:

I was so pissed about this I immediately called my wife and we agreed to cancel. They sent me a generic BS email a couple of days later saying “You spoke, we listened…”. But they didn’t think far enough ahead to make an offer to people like me to actually re-sign up. I sure ain’t gonna go out of my way to sign up again so they messed up twice.

Managing Software Development with Trac and Subversion

El libro "Managing Software Development with Trac and Subversion" de "David J Murphy" es el primer libro de Trac que salio, y debido a mi gran amor por Trac, tuve que conseguirlo. Realmente me desilusiono bastante, porque es muy corto y no entra en muchos detalles sobre Trac (un software de administración de proyectos web que recomendé anteriormente).

El libro empieza con practicas básicas de administración de proyectos y luego cuenta como llevarlas a cabo con Trac. Debido a mi experiencia con el sistema, conocía la mayoría de lo que se comentaba en el libro, pero me sorprendí de varias cosas que desconocía.

Para un principiante en Trac se los recomiendo, ya que además tiene una muy buena guia de instalación. Les dejo el articulo libre "Software Documentation with Trac" del libro.

Lanzamiento de Trac 0.11!

Estoy muy contento de anunciar que ya salió Trac 0.11. Trac es un software de administración de proyectos web que recomendé anteriormente. Les dejo el anuncio oficial de Jonas Borgström del grupo de Trac en Google:

Trac 0.11
=========

We're happy to announce the much awaited Trac 0.11 release.

You will find this release at the usual place:
http://trac.edgewall.org/wiki/TracDownload

Here are some of the features you can expect from this version:

* New template engine for generating content (Genshi)
* New configurable workflow in the ticket subsystem
* Finer-grained control of permissions
* Support for Pygments as the default syntax highlighter
* Improved repository browser ("blame" support, dynamic in-place
expansion of folders)
* Improved user preferences subsystem, among which the possibility
for any user to select their time zone and disable access keys
* The WebAdmin plugin is now an integral part of Trac

You can find a more detailed release note at:
http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.11

Acknowledgements
================

Many thanks to the growing number of people who have, and continue to,
support the project. Also our thanks to all people providing feedback
and bug reports that helps us make Trac better, easier to use and more
effective.
Without your invaluable help, Trac would not evolve. Thank you all.

Finally, we offer hope that Trac will prove itself useful to like-
minded programmers around the world, and that this release will prove an
improvement over the last version.

Please let us know. :-)
/The Trac Team http://trac.edgewall.org/

Asignando desarrolladores Juniors para realizar tareas complejas: Cuando el cliente se da cuenta

En mi primer trabajo, en un proyecto en el cual teníamos que hacer unas tareas de mantenimiento para un cliente, me asignaron a mí para comunicarme con él y un desarrollador junior para llevar a cabo la tarea. Luego de unos días de trabajo recibo por IM lo siguiente del cliente:

I'm a little concerned right now because once the fields are known, the process to import the data shouldn't take very long. I'm starting to question what the team has been doing for so many days.

El cliente tenia razón (¿no la tiene siempre?). No era una tarea muy compleja, un desarrollador con más de un año de experiencia la sacaba en unas horas y ya llevábamos varios días. Estas son situaciones difíciles para los Project managers. A uno le asignan recursos, y a veces tiene que tratar de alargar los tiempos lo más que pueda con el cliente. En esta situación lo que hice fue comunicar esto a mi superior y asignamos a alguien para que resuelva la tarea y lo pudo hacer en unas horas. Yo había avisado que estábamos bastante atrasados, había cumplido con mi deber.

Esta es una de las tantas situaciones incomodas que los Project managers tienen que enfrentarse. La única solución que veo es escalar para arriba si uno no maneja los recursos de la empresa (siendo Project manager es imposible controlar esto).

Desarrollando software de a tres empresas

En el proyecto de creación de la librería de software para un producto de “Software Asset Management / License compliance” nosotros nos encargábamos de armar la librería (que era una base de datos que era procesada por una página web de validación de datos) y un equipo en la empresa del cliente estaba desarrollando el producto que iba a utilizar nuestra librería. Realmente la comunicación entre los líderes técnicos de ambos proyectos eran conflictivas. Este podría ser el esquema:

El líder técnico del cliente no se esforzaba por entender nuestros conceptos, y nosotros no podíamos transmitirlos de la mejor manera. Entonces el Sponsor del proyecto contrato a un consultor externo de una empresa ubicada cerca de la empresa cliente que sabia ingles. Esto realmente soluciono todos nuestros problemas y durante el tiempo que trabajo, ayudo a armar la comunicación entre la librería y el producto y quedamos todos contentos como se puede ver en el siguiente esquema:
Obviamente que no podemos culpar solo al líder técnico del cliente, ya que seguro que de alguna forma nosotros fallábamos al no poder hacernos entender. La contratación de un tercero podría haberse prevenido si no hubiesen existido los problemas de comunicación, pero hay veces que estas cosas son necesarias y miradas frescas influyen positivamente en los proyectos.

Cuando la fecha de entrega no es el factor decisivo

Hace poco un cliente envió en un mail la siguiente frase:

"Delivering on a date is a desire; delivering an application that functions correctly is an absolute must"

Realmente da gusto recibir este tipo de comentarios. El mundo no se termina si se atrasa una fecha de entrega (En sistemas no críticos). Realmente hay que poner todo sobre la mesa y decidir que es mas importante, si entregar algo con fallas o tomarse el tiempo para arreglarlo y tardar un par de días mas.

Muchas veces las fechas son decididas por gente que no comprende las complejidades inherentes del software y que no vienen de la mano de algún problema del negocio. Hay casos que una fecha es necesaria, esto es por ejemplo cuando hay que sacar un producto a producción en cierta fecha debido a que entra en vigencia alguna posposición legal. En esos casos no se pueden retrasar las fechas, y hay que tener mas cuidado con las estimaciones para poder llegar a tiempo.

Páginas personales – Mi vida Web!

Últimamente están de moda las páginas personales. El propósito de estas páginas es cargar la información que uno necesita en una sola página, sin necesidad de visitar varias páginas distintas constantemente. Además se pueden agregar un montón de aplicaciones con distintos propósitos. Hay un montón de páginas, pero yo elegí iGoogle, ya que últimamente utilizo un montón de servicios de Google, y es muy cómodo necesitar solo un usuario y contraseña para una gran variedad de servicios.

Hace aproximadamente un año inicie un proyecto personal para crear "mi vida web":esto es organizar todos mis datos en la web, tratando de lograr independencia de una computadora. Mi objetivo es lograr poder hacer todo lo que necesito desde cualquier maquina, desde un browser. Para eso elegí Google:

• Utilizo Gmail como correo principal, tengo todos mis contactos y sus datos ahí.
• Utilizo Google Calendar para calendarizar compromisos y recordar cumpleaños entre otras cosas.
• Utilizo Google Notebook como bloc de notas para escribir lo que sea.
• Utilizo Google Reader para recibir todas las actualizaciones de páginas que me interesan por RSS.
• Utilizo Blogger para publicar este Blog.
• Utilizo Google Docs (Ya expliqué mis aplicaciones en un post anterior).
• Uilizo Google Bookmarks (Ya lo comenté en un post anterior).
• Utilizo Picasa Web Albums para guardar todas mis fotos online.
• Utilizo iGoogle como página personal para acceder a todo el contenido desde un solo lugar.

Lo único que me faltaría seria que lancen GDrive para poder guardar mis archivos ahí, y que lancen la nueva aplicación Update de iGoogle para poder obtener el “news feed” de Facebook sin tener que entrar a la pagina para verlas.
En iGoogle también tengo las siguientes aplicaciones que me permiten:

• Ver los contenidos de mi cuenta de Hotmail
• Ver el estado del clima y el pronosticó
• Anotar Sticky notes
• Tener una To-Do list (con prioridades)
• Tener links a las aplicaciones de Google que uso y no están en mi página personal, como Blogger, Groups, Bookmarks, Picasa Web Albums y Documents.

Les recomiendo que prueben tener una página personal, sea en iGoogle o donde quieran, ya que les facilitara tremendamente la vida.
Les dejo para que lean este interesante artículo donde comparan distintas páginas personales.

Extreme Programming Explained

El libro "Extreme Programming Explained" de Kent Beck y Cynthia Andres es un libro muy conocido sobre Expreme programming, o "XP", las siglas por las cuales todos la conocemos. Kent Beck es el creador de XP.

XP es una metodologia de desarrollo de software agil. La conocía vagamente por algunas clases en la facultad y este libro realmente enriqueció mi conocimiento sobre XP. No es para nada un libro técnico, es un libro que explica la metodología, los valores, principios y practicas de XP.

Realmente lo recomiendo a cualquier persona que le interesen las metodologías de desarrollo de software, ya que la metodología (y el libro) es sumamente interesante y estoy de acuerdo con sus valores, aunque siempre hay que tener en cuenta las controversias. Esta es una imagen del autor que resume las practicas, valores y principios de XP.

Actitudes de un líder: Generación de confianza

Les dejo diez consejos prácticos para generar confianza en el marco de la gestión de proyectos, los cuales fueron publicados en el blog de Mejores Proyectos (realmente recomendado):

1. Tener en claro las expectativas de los stakeholders, y si no serán alcanzables informarlo lo antes posible.
2. Prometer solo si se está seguro de que se podrá cumplir, o en caso contrario solo comprometernos a intentarlo. No hablar de más, somos PMs no vendedores.
3. Ser y mostrarnos abiertos en las discusiones, mostrando nuestros puntos de vista e intereses, y tratando de crear soluciones ganar-ganar.
4. Comunicar claramente objetivos y expectativas al equipo.
5. Crear entregables tempranos, y cumplir rigurosamente con sus entregas, por ejemplo minutas de reunión, entrega de información, respuestas, entregas parciales.
6. Ser prolijo en la relación, mantener las formalidades.
7. Ser puntual. Muy puntual. Siempre puntual.
8. Ser prolijos en nuestro aspecto personal, vender la imagen.
9. En las primeras instancias del proyecto no cometer errores ni incumplir con las obligaciones, no importa que tan pequeñas sean estas. No hay una segunda oportunidad para una primera impresión.
10. Utilizar nuestra reputación dentro de la compañía como referencia para iniciar la relación con el nuevo equipo de trabajo.

También puedo agregar que es muy importante conocer al equipo, individualmente a cada persona, para ver que puede dar, que intereses tiene, que busca y llegar a lograr confianza mutua.

Propuesta para cambiar el proceso de administración de tareas - Parte 3

Debido a la fusión que anuncie ayer, mis superiores decidieron no cambiar nada en el proceso de administración de tareas (Para la cual había hecho una propuesta de mejora) todavía, ya que no es un buen momento para realizar un cambio y estoy de acuerdo.

Debido a que nos vamos a unir, tendremos que evaluar las practicas de ambas empresas, adoptar las practicas que tienen ellos que son mejores que las nuestras y viceversa: lograr que ellos adopten las practicas que son mejores que las de ellos, sea en el área que sea.

Espero que la historia no se termine acá y que tenga la posibilidad de implementar el proceso que sugerí, o lo que es mejor, conocer otras herramientas y procesos superiores, que seguro tienen que existir.

Demasiadas fusiones para mi corta vida

Al mes de comenzar mi nuevo trabajo me entere de que nos íbamos a fusionar con otra empresa. Dada a una experiencia no completamente grata de una fusión en mi trabajo anterior, realmente tome la noticia con cierta apatía.

Recuerdo que en la otra oportunidad no se cumplieron las promesas de la fusión anterior, por las cuales tenía grandes expectativas y entusiasmo.

Ahora tome la resolución de tomarme el cambio con calma, sin euforia pero también sin negatividad, ya que creo que una mala experiencia tiene que predisponer mal a alguien, pero si crear algún sentido de precaución para el futuro.

Recuerdo que en el anuncio de la fusión preguntaron si alguien había pasado por un proceso similar, pero yo no dije nada, no quería tirar experiencias negativas para algo que puede ser más que positivo.

Debido a muchos factores hay grandes posibilidades de que esto sea un éxito. Realmente espero que lo sea y voy a dar lo mejor de mí para aportar mi granito de arena.

Microsoft Virtual Server y VMware Workstation

Cuando hacia testing en mi primer trabajo usábamos maquinas virtuales para probar la aplicación en distintos sistemas operativos. Una maquina virtual es un archivo que se abre con un programa en el cual se le puede cargar cualquier sistema operativo (En realidad depende del producto) y este sistema operativo lo representa y lo virtualiza fielmente. Entonces uno puede saber como se va a comportar la aplicación en distintos sistemas operativos. Además se pueden tener muchas maquinas virtuales en una sola computadora, asignarle el RAM que uno necesite para cada una y correr muchas a la vez entre otras cosas.

Microsoft Virtual Server fue el primer producto de virtualización que utilice. Realmente es solido, estable y no tuve problemas.

Luego en otro proyecto un cliente nos mando una maquina virtual de VMware así que tuvimos que conseguir el VMware Workstation. Realmente me gusto mas este producto, debido a que tiene una funcionalidad para guardar estados ("Snapshots") de cualquier maquina virtual y se puede volver al estado que uno quiera. En Microsoft Virtual Server existe la opción de crear un disco de recuperación, el cual uno va salvando, pero no permite guardar múltiples estados, solo uno.

Las herramientas de virtualización están en crecimiento por sus comodidades y posibilidades en el ambiente laboral.

Accediendo a tu PC desde cualquier lado con No-IP

No-IP es un servicio que permite publicar tu IP a una dirección del tipo: yourname.no-ip.com. Además, si tenés IP dinámica, podes instalar un cliente en tu maquina que publica la IP.

Yo uso esto para acceder a la computadora de mi casa desde cualquier lado mediante la aplicación de escritorio remoto de Windows (Es necesario configurar Windows para permitir esto). Es muy cómodo acceder a cualquier aplicación o documento de tu casa desde cualquier lado.

No-IP también ofrece servicios profesionales de DNS, mails, monitoreo y registro de dominios.

¿Qué es un SLA (Service Level Agreement)?

Un SLA (Service Level Agreement) o "Acuerdo de nivel de servicio" en castellano, es un documento que define relaciones entre dos partes, el cliente y el proveedor. En el software se escriben este tipo de documentos en cualquier caso que se preste algún tipo de servicio. El objetivo de este documento es:

• Identificar y definir las necesidades del cliente
• Proveer entendimiento entre las partes
• Simplificar temas complejos
• Reducir áreas de conflicto
• Promover dialogo en caso de disputas
• Eliminar expectativas pocos realistas

Específicamente debe tratar un gran rango de temas, por ejemplo:

• Servicios a entregarse
• Rendimiento, seguimiento, formas de reporte
• Administración de problemas
• Procedimientos legales para la resolución de problemas
• Tareas y responsabilidades de los clientes
• Seguridad
• Confidencialidad de la Información
• Terminación del contrato

Para mas detalles lean este articulo. También les dejo una plantilla muy interesante de un SLA.