Midiendo la calidad del código: WTFs por minuto

Software y Poesía

Les dejo esta comparación entre desarrolladores de software y poetas que hace Alistar Cockburn en el libro "Agile Software Development". Muy interesante!

What if software development were not software development? Then what would it be, and what would the experience be like? I suggest that it is like a community writing epic poetry together. I make this comparison not because I think you have experience in community poetry writing, but because I think you don't. Your imagination will supply you with the sorts of contradictions I am interested in evoking.

Imagine 50 people getting together to write a 20,000-line epic poem on cost and time. What would you expect to find? Lots of arguments, for one thing. People trying to be creative, trying to do their best, without enough talent, time, or resources.

Who are the players in this drama? First, the people who ordered the poem. What do they want? They want something they can use to amuse themselves or impress their friends, not too expensive, and soon.

Next we have the key poem designers.

As you might imagine, this began as a one-person project. But our mythical poet found herself promising much more than she could deliver in the given time frame. So she asked a few friends to help. They designated her the lead poet and poem designer. She blocked out the theme and the poem's sequencing.

Her friends started to help, but then they ran into problems with synchronizing and communicating their work. It also turned out that they couldn't get it all done in time. So they added a couple of clerical people, more friends, and in desperation, even neighbors. The friends and neighbors were not real poets, of course. So our lead designers blocked out sections of the poem that would not require too much talent.

What do you think happened?

There was good news: One person was good at descriptive passages, another was good at the gory bits, and another was good at passages about people. No one was good at emotion except the lead poet, who by now was pulling her hair out because she didn’t have time to write poetry, she was so busy coordinating, checking, and delegating.

Actually, a couple of people couldn't leave well enough alone. Two of them wrote pages and pages and pages of material describing minor protagonists, and our lead poet could not get them to cut it down to size. Another few kept rewriting and revising their work, never satisfied with the result. She wanted them to move on to other passages, but they just wouldn't stop fiddling with their first sections.

As time progressed, the group got desperate and added more people. The trouble was that they were running out of money and couldn't really afford all these people. Communications were horrible, no one had the current copy of the poem, and no one knew the actual state of the poem.

Let's give this story a happy ending...

As luck would have it, they engaged a wonderfully efficient administrator who arranged for a plan of the overall poem, an inventory of each person's skills, a time-frame and communication schedule for each part, standards for versioning and merging pieces of the poem, plus secretarial and other technical services.

They delivered the poem to satisfied clients, well over budget, of course. And the lead poet had to go on vacation to restore her senses. She swore she would never do this again (but we know better). Groups have surely have gotten together to write a long poem together. And I am sure that they ran into most of the issues that software developers run into: temperamental geniuses and average workers, hard requirements, and communication pressures. Humans working together, building something they don't quite understand. Done well, the result is breathtaking; done poorly, dross.

Hug a Developer Today

Impresionante video sobre las penurias de los desarrolladores de software. No se lo pierdan

Developing The Leader Within You

Este es el primer libro de liderazgo que leo, y realmente es muy entretenido e interesante. John Maxwell escribió muchos libros de este estilo (estimo que entre tantos debe haber bastante superposición de temas). El tema principal del libro es desarrollarse uno como persona para enfrentar un puesto de liderazgo o mejorar y dar lo mejor de uno en todo lo que hace.

Personalmente, lo que más rescaté es la forma en que me hizo dar cuenta de la importancia de dar el ejemplo, entre muchas otras cosas. Creo que este libro me marco y me dejo pensando sobre muchas cosas de mi personalidad sobre las que tengo que trabajar para hacer las cosas mejor, y eso lo veo como algo muy valioso.

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.

Como aprovechar LinkedIn profesionalmente y al máximo

Hace poco me encontré con este interesante artículo, que indica cómo aprovechar LinkedIn, una red social que recomendé en un post anterior.

Para los que recién comienzan a utilizar este tipo de red social, les recomiendo que le peguen una mirada al artículo, para aprender cómo aprovecharla mejor y conocer la aplicación al máximo:

Leer Artículo.

Historias del correo: Encomienda sorpresa y tazas rotas

En mi primer trabajo, cada vez que me enfermaba y no podía ir a la oficina pasaba algo extraño. No eran problemas de trabajo ni con los clientes, solamente sucesos fuera de lo normal.

Por ejemplo en el primer proyecto en el cual trabaje, me hice muy amigo de la persona que se encargaba de soporte al usuario de la empresa en Estados Unidos. Me conto que tenían en un deposito unas tazas con el nombre del proyecto, ya que era un producto de uso masivo y le dije que gestione para que manden algunas para acá.

Unos días antes de mi cumpleaños me enfermé. Justo ese día me llamaron diciendo que llego un paquete para mí con el nombre de la clienta. Yo pensé que eran las tazas y les dije que lo reciban (El tema era que Fedex pedía 300 pesos que es lo que habían cobrado la aduana).

Quince minutos luego me llama un compañero diciendo que los contenidos del paquete eran algo personal, que era para mí y que era una sorpresa. También me comento que escucho decir a uno de los jefes que tenía que pagar yo los 300 pesos, lo cual no me causo mucha gracia.

Luego de que me recupere volví y había en mi escritorio una caja de un monitor LCD. Realmente me emocione pero eso fue una broma de mis compañeros, que habían puesto la el paquete adentro de la caja del monitor, con una hoja impresa con la conocida imagen de Nelson (personaje de los Simpsons) diciendo “Ha ha”.

Adentro de la caja había un montón de pequeños regalos de la clienta de Estados Unidos por mi cumpleaños. Me había mandado un montón de chocolates (los cuales compartí), un CD del guitarrista Joe Satriani, un CD de una cantante amiga de ella, una remera de una cervecería que me quedaba chica (ahora que recuerdo la tiene una ex novia, maldición), una polvo para cocinar una Cheesecake instantánea, unos fideos con salsa para calentar por microondas, un café muy raro, una sopa instantánea de papa, un gel de chocolate energizante y alguna que otra cosa más que no recuerdo.

Fue muy emocionante y grato recibir esto, realmente me sorprendió, fue el primer regalo personal de un cliente que recibí (y el único hasta hoy). Luego de unos días me dijeron que los 300 pesos los pagaba la empresa ya que era lo que correspondía por ser un regalo empresarial aunque de carácter personal.

Luego de unos meses, volví a enfermarme y me volvieron a llamar. Había otra encomienda, esta vez si eran las tazas, pero de 12 sobrevivieron 3 nada más (y con bastantes rayones). Ahora que estoy en otra oficina las extraño.

Perdiendo dos horas de trabajo por un error de la aplicación

En mi primer día en mi nuevo trabajo, tuve un grave problema con el Microsoft Project 2007. Era bastante tarde y el líder de proyecto al que reemplazaba me estaba explicando cómo hacer el informe de estado del proyecto, en el cual se entrega el calendario actualizado.

Luego de dos horas de trabajo habíamos terminado y cuando nos dispusimos a cerrar el Microsoft Project seleccionamos cerrar y presionamos que queríamos guardar los cambios realizados en el documento. Lamentablemente, apareció un mensaje informándonos de un error para el cual no había opción de volver atrás, solo daba la opción de presionar OK.

Luego de hacer clic (no había otra salida) nos dispusimos a abrir de nuevo el archivo y vimos que no se había salvado ningún cambio.

Nos tuvimos que quedar a rehacerlo (en otra máquina por las dudas) y nos fuimos casi dos horas tarde. Era un viernes, y yo salí maldiciendo mi nuevo trabajo. Por suerte eso no ocurrió mas.

Realmente es lamentable que la versión 2007 del Project no tenga ningún sistema de recuperación de datos, como tiene el Word 2007 por ejemplo (y creo que el 2003 lo tenía también). Es inconsistente que Microsoft lance aplicaciones del mismo paquete que no tengan las mismas funcionalidades que en estas épocas son consideradas básicas.

La tarea más frustrante que tuve que hacer hasta ahora – Parte 2

Ayer les conté sobre una tarea que tuve que realizar sobre SMS (Microsoft System Management Server 2003), que comparada con lo que contare ahora fue un “pedazo de torta” o un “paseo en el parque” (Traducción de las frases “A piece of cake” y “A walk in the park” que en ingles significan que algo fue sencillo).

En otro proyecto, para otro cliente, que lamentablemente usaba el mismo sistema, tuvimos que preparar un parche para una aplicación que tenía que ser .exe, y distribuirlo en una red SMS (que generalmente acepta archivos de instalación .msi). Esto hubiese sido más simple si hubiésemos tenido que trabajar en el dominio con el servidor y el cliente que venía preparado por Microsoft , pero teníamos que probar con una maquina virtual que nos había mandado el cliente para distribuir el software desde el servidor.

Inicialmente se agrego la maquina al dominio y costó mucho para que el SMS la reconociese. Por suerte estaba presente la persona que conocía parcialmente SMS, la cual me ayudo mucho.

Finalmente logre que se vean las dos maquinas y comencé a hacer las pruebas de instalación del parche por SMS.

Algo funcionaba mal, había veces que se comunicaban las maquinas, y veces que no. Veces que tardaba unos minutos en aparecer la instalación del programa, y veces que tardaba horas, con la misma configuración.

Estuve muchos días con esto, me sentía muy frustrado ya que quería terminar la tarea, volvía a mi casa triste, no podía olvidarme, ya que necesitaba algún progreso o alguna indicación de mejora para sentirme bien. Además, fueron mis últimas semanas de trabajo. No logre terminarlo. Realmente me dejo un gran sabor amargo, que solo lo puede disminuir el hecho de que no fui entrenado ni realmente me apasiona el trabajo de infraestructura. Luego seguí comunicándome con compañeros para ver en que había quedado la tarea, y parece que luego de un tiempo se pudo completar.

Espero no toparme con SMS en lo inmediato, pero sé que adquirí gran conocimiento del sistema si es que me toca, para terminar el post en un tono alegre.

La tarea más frustrante que tuve que hacer hasta ahora – Parte 1

Les voy a contar sobre la tarea más frustrante que tuve que hacer en el trabajo (en mi primer trabajo) hasta ahora. Esta involucro un producto de Microsoft (no podía faltar, en las malas más que en las buenas), el Microsoft System Management Server 2003 (coloquialmente conocido como SMS). Este software sirve para instalar automáticamente software en una empresa desde un servidor y para tener una base de datos de todos los archivos y programas de todas las computadoras (entre otras cosas).

Mi primer encuentro con este software fue cuando estaba trabajando en un proyecto de construcción de una librería de software en un proyecto de Software “Asset Management/License compliance”. Nuestra librería se rellenaba con datos recolectados por SMS, y como había salido el Microsoft Office 2007, el cliente quería ingresar ese software (en todas sus ediciones) en la librería.

Siempre recibíamos copias de seguridad de la base de datos de SMS de empresas para ingresarlas a la librería, pero esta vez nos pidieron que nos encarguemos nosotros. Por suerte Microsoft distribuye a sus partners un ambiente de prueba de SMS, con una maquina virtual que es el servidor de SMS, y un cliente en el mismo dominio. Se instaló en la maquina virtual cliente el Office 2007 y luego comencé a trabajar con la consola de administración del SMS para que se recolecten los datos de la maquina cliente y poder darle ese base de datos al desarrollador para que se importe en la librería.

Decir que configurar el SMS fue difícil es ser muy bueno con la palabra difícil. Realmente fue muy complicado y frustrante, ya que es un sistema bastante complicado, y no me deberían haber asignado la tarea a mí, tendría que haberla visto alguien de tecnología, y justo en ese momento el único que tenía idea estaba en un cliente por un largo tiempo.

Luego de varios días de leer tutoriales y probar, logre llenar la base de datos con los archivos del Office 2007. Realmente fue muy gratificante haber terminado esa tarea. Creo que cuanto más difícil es la tarea, más gratificante es terminarla con éxito. Realmente no tenía tiempo para ponerme con una aplicación compleja sobre la cual no recibí ningún tipo de entrenamiento formal e informal.

Siempre uno se va a encontrar con tareas frustrantes en el trabajo. Hay que tratar de que no lo agobien a uno y tener mucha pero mucha paciencia y atacar la tarea día a día.