El mundo de la tecnología de la información evoluciona cada día.

Acompañando las noticias de blogs descubrimos nuevas tecnologías, lenguajes, patrones y muchas cosas más.

Mientras tanto, para ganar el pan de cada día  nos vemos en la necesidad de respetar lo que hacemos acá (trabajo), después de todo es el resultado de nuestro esfuerzo lo que genera la remuneración que pone la comida sobre la mesa en casa.
Bueno, trabajar con algo no impide que usted tenga interes en otra cosa. Pero cuando empezamos a buscar sobre varias cuestiones nuevas descubrimos que aquella tecnología que considerabamos nueva ya es utilizada por las empresas durante dos o tres años y ya se discute el cambio por otra más joven aún.

Verifique estas 10 preguntas que describen el entorno en el que usted trabaja:

1 - ¿Su herramienta para el control de versión es el CVS o Source Safe?
Sí, he visto varios debates sobre el mejor sistema de control de versión, algo que es un poco subjetivo, pero una cosa es cierta: CVS ya es el pasado.
Casi todos los proyectos de código abierto más importantes que conozco desde hace años trasladaron sus archivos a SubVersión, que hace todo lo que CVS con muchas mejoras. Hoy se discute también el uso de Git, que actualmente es quien tiene la ardua tarea de la gestión de la enorme equipo de desarrolladores del kernel de Linux.

2 - ¿El nuevo lenguaje que usted tiene más de 10 años?
No me refiero a su principal lenguaje de desarrollo, sólo al lenguaje mas nuevo en que usted desarrolla, aunque sólo sea de vez en cuando.
Si usted trabaja en cualquier banco, probablemente sea Cobol, que es de 1959 y tiene 48 años.
Usted trabaja con C? es de 1972 tiene 35 años! C + +? Esta es de 24!
Usted puede pensar: "Yo no, yo soy moderno, de programo con Java". Sí, también cuenta con 12 años ya!
Y PHP no está muy a la zaga, ya tiene sus 13 años, seguido de ASP con 11.

3 - ¿El proceso de despliegue de su empresa no es automático?
Si usted trabaja en una empresa mediana o grande, debe tener al menos un entorno de desarrollo, uno de homologación y pruebas, y otro para producción.
Por lo general, el paquete que usted ha hecho y colocó en desarrollo precisa ser replicado en otros entornos.
Si esto se hace manualmente, además de la pérdida de tiempo, existe también el problema de error humano, por ejemplo puede pasar que un paquete podría estar subir equivocado al ambiente de aprobación o producción.
Algunas empresas que tienen automatizado todo en el entorno UNIX, donde usted simplemente comitea y el servidor hace todo el resto. La más moderna apuesta por otras soluciones, tales como Apache Continuum, Cruise Control, Hudson.

4 - ¿Su empresa no ofrece acceso remoto?
Tenemos que hacer un ejercicio de rutina ahora, 4 de la mañana un sábado y usted no tiene más remedio que ir personalmente a la empresa a hacer eso?
Si eso para ti no es lo normal, pero, evidentemente, sabemos que muchas empresas usan soluciones propietarias u open source para hacer todo sin salir de casa.

5 - ¿Las herramientas Open Source se consideran lo mismo que herramientas Gratuitas?
Este concepto de "software libre" viene de una mala interpretación de Inglés, donde además de gratuita en algunos contextos puede significar libre, sin trabas. El ejemplo clásico de uso de Gratuito es "cerveza gratis" y libre cómo "la libertad de expresión".
¿Y por qué usted debe tratar las herramientas open source y gratuitas diferente? Ni siquiera todas las gratuitas de la misma forma?
Bueno, la razón es muy simple. Una herramienta gratuita no tiene su código fuente abierto, lo que puede ser peligroso.
Imagine que su empresa adopte un software propietario gratuito en algún proceso, y en pocos meses esta herramienta se ha convertido en esencial para su trabajo. De repente, en una actualización de software, descubre que la herramienta ahora es propietaria y no la puede utilizar más! ¿Y ahora? Todo su esfuerzo fue en vano? ¿Cómo convencer a tu jefe ahora a desembolsar dinero en una licencia?
Con proyecto de código abierto eso no ocurre, pero también tiene sus inconvenientes, que por lo general no tiene el apoyo técnico y al igual que el proyecto podría ser abandonado si nadie quiere tomarlo, aunque uno siempre podría tomarlo si es necesario.

6 - ¿Linux se considera algo de un estudiante?
Hay empresas que todavía tienen la imagen de que Linux es aquel donde aparece la pantalla en negro con el cursor de login parpadeando y que sólo un estudiante puede pasar a "jugar red".
Sólo IBM ya tiene 15 mil clientes con Linux y Oracle también invierte significativamente en ese mercado.
Si se tratara de algo de estudiantes, habría tantos "grandes" ganando dinero de esto?
Y hay mas, por favor, no comente con alguien que Linux no tiene entorno gráfico, esto puede ser motivo de broma ...
Linux tiene varios tipos de entornos gráficos, desde los más completos como KDE y Gnome, como los mas levescomo Fluxbox y WindowMaker. Además, tiene excelentes efectos visuales, algunos incluso sirvieron de inspiración y se incluyen en Windows Vista.
El Beryl es un proyecto que se ocupa de tales mejoras visuales.

7 - ¿Utilizan versiones antiguas de software propietarios?
Usar versiones antiguas de software propietario suele ser un problema grave, porque la tecnología actual no funciona por sí sola, ella siempre se integra con otras, tal vez open source, que es probablemente más actual e incluye más opciones.
La peor parte es cuando usted tiene un problema y la solución que el proveedor le da es simplemente la frase: "actualice su software". Y convengamos, que tiene motivos para pedir eso. Imaginemos que tenemos un proveedor de aplicaciones de Windows, sería viable mantener las versiones para Windows 3.1?

8 - ¿"Esta es la norma" es la excusa utilizada para justificar la ignorancia?
En un debate de alto nivel, por lo general las personas recientemente contratadas cuestionan algunos comportamientos en algunos problemas. Si la solución adoptada por la empresa es viable, tendrá argumentos para sostener la actitud, sino puede ella puede simplemente acomodarse en el mar de la ignorancia y decir en la cara: "Mira, esto aquí es normal, alguien decidió eso antes y no tienen que discutir ". ¿Qué tenemos como resultado?
Normalmente, además de la pérdida de dinero, tenemos repartidos en algunos blogs algunas perlas de la tecnología de la información.

9 - ¿Las pruebas de software son pérdida de tiempo?
Y corregir un error es para ganar tiempo por casualidad?
No, todo lo contrario, usted para arreglar un error pasa mucho más tiempo que para crear una prueba.
Eso sin hablar de la refactorización, con las pruebas usted puede hacer refactoring sin temor de ser feliz. =)
Tener un equipo de calidad garantiza un software mas maduro para los usuarios. No cabe duda de que es mejor un informe de errores de personal de calidad, que el usuario reclamando a su jefe.

10 - ¿Metodología ágil es desarrollar y corregir los errores al mismo tiempo?
No, no, el manifiesto ágil describe bien lo que la metodología ágil propone, que se resume en cuatro temas:

• Las personas y las interacciones en lugar de los procesos y herramientas
• Operativo de software en lugar de una amplia documentación
• La colaboración del cliente en lugar de negociación de contrato
• Responder a los cambios en lugar de seguir un plan

Hoy se habla mucho de XP y Scrum, y leean sobre ello, escuchen podcasts, y experimenten.

Si usted ha identificado la mitad de los temas, felicitaciones, pertenece a Jurassic Park.

Traducción libre.