Tercerización de servicios (y la seguridad asociada)

Una de las cosas con las que frecuentemente solemos toparnos los desarrolladores, consultores y tecnócratas en general, es con la administración de permisos y seguridad en las redes. Si se tiene una empresa pequeña, unos 25 empleados en plan Fabrica de Software, pues.. lo normal es que todos los desarrolladores sean administradores locales, se establezca una política para subir cambios a un entorno de Desarrollo común, estable. Pasadas las pruebas del equipo de desarrollo, pasamos a un ambiente de pre-producción donde otras personas ejecutan sus test. Esto.. en plan pequeño.
Que sucede cuando nuestra compañía es una empresa de mas de 100 empleados, con personas con computadores portátiles, y donde hay tercerizados (esto es, nuestra empresa sub-contrata a otras empresas para labores específicas)? Cómo se determinan los privilegios administrador/usuario avanzado/colaborador/solo lectura?
En mi recorrido, creo que una práctica sana sería: los desarrolladores como usuarios restringidos en sus equipos, pero con una máquina virtual con la que puedan "trastear" y desarrollar. Políticas de supervisión de navegación en el proxy para limitar las cosas que pueden acceder (dudo que Youtube tenga algo interesante para un programador). Si el requerimiento es prohibir a los usuarios estar todo el dia conversando por MSN/GTALK (que me parece iluso, uno puede ser tan o incluso mas productivo y usar estas herramientas), algun cliente de mensajería que puedan usar los miembros del equipo de desarrollo, pero que no permita comunicación web (algo tipo MS Comunicator). Un servidor de fuentes, y una política acertada de cambios en servidores (a desarrollo puede ser diaria, mientras que a otros entornos, semanales o mensuales). A los miembros tercerizados, se les pudiese crear un "grupo" de Active Directory con pemisos similares a los del grupo de desarrollo local.
El asunto que vendría a complicar todo es: quien maneja el AD? personal de la empresa, o se subcontrata? esto es un asunto espinoso, ya que hay empresas en las que la burocracia y procedimiento de cambios en ambientes de explotación, suelen demorar mucho y pasar por tantos niveles, que mas que controlar la seguridad, entorpecen el desarrollo y mantenimiento de aplicaciones.

Rompiendo los ladrillos

De jovencito, recuerdo mi fascinación por los tipos que rompían ladrillos a punta de golpes: Manos, cabeza, piernas, rodilla. Todo era permitido. Me los imaginaba super fuertes. Un día, mi primo, que de eso sabía bastante, me indicaba no lo rompes solo con una parte del cuerpo, sino con todo el cuerpo. El peso ejerce un enorme poder al momento de transmitir algo....

Recuerdo también la "estela de la destrucción": los ladrillos que estaban arriba tenian pequeñas fracturas que a medida que se descendía, era mayor. Hasta llegar a los últimos ladrillos que quedaban desmenuzados.

Ya de "mayorcito" me he fascinado al ver como ese mismo fenómeno se repite en las oficinas. El Jefe Superioris está haciendo algo y le falla un sistema (digamos, un hipervínculo no se muestra en una página web). Comienza el proceso de "estela de destrucción": el dichoso jefe transmite a un gerente de primera linea (el CIO, el responsable de TI, etc, etc etc) la "incidencia" con un "sabes que me pasó esto". Empieza allí el calvario: "ya te envío a alguno de los muchachos para que lo resuelva" o "Que raro? ese comportamiento no es normal". Sigue un "vamos a escalarlo con el personal apropiado para verificar el porqué ocurre eso". Frases acartonadas van y vienen cual manual de protocolo. Y así comienza la estela. El gerente de primer nivel le dice al de segundo "el Jefe me manifestó que hay algo en la aplicación X que no le funciona". El de segundo al de tercero: "el jefe/dueño/manda más/chivo que mas mea/papá de los helados le dijo al gerente qe algo no le funciona". y sigue con un "el XXX le armó un rollo al gerente porque algo no le funcionó, y nos están presionando para que lo resolvamos lo mas pronto posible" hasta que llega al último nivel:
- Se presentó una incidencia, la aplicación falló totalmente (la desmesura de las palabras y lo exagerado de la situación) mientras la usaba el sr. Fulanito, se han encendido varias alarmas porque es algo que no salió en ninguna prueba...
- Disculpa, fulano... una pregunta..... según veo aquí, la incidencia es porque las palabras que constituyen un hipervínculo.. el mouse no cambia de puntero a la manito típica ni se subraya...
- Eso es correcto, pela_patatas_01
- Vale.. Es que.. según el correo enviado por el subgerente_posición_51 cuando la definición de requerimientos, dijeron que no querían que los hipervínculos tuviesen el subrayado ni el cambio del mouse, ya que querían que fuese un texto lo mas compacto, ultraliviano y que nada destacase por encima del resto de las palabras.....

Sorpresa, sorpresa. Comienza entonces una serie de reuniones con usuarios, gerents, desarrolladores, el Papa Juan Pabl.. ahh, que ahora es Ratzinger. Bueno.. en fin. La negociación típica de plazos, de eso no estaba en los requisitos iniciales, que el cambio cuesta tanto, que eso es mucho dinero para algo tan minúsculo, que si, que si no.. que es para el gerente, que se aprueban los 200 mil $ presupuestados... y al final, son los pobres programadores luchando para ver donde rayos estaba el condenado 'a href' que fallaba, con un plazo de 2 días, y si no lo cumples, corre que te despido!!

En fin.. que la terminan pagando los curritos, mientras que el jefe superioris se sorprende que el gasto de su departamento de TI se gaste 200mil $ colocando un 'a href'.. ahh.. no.. en un "proyecto de actualización, mejora y upgrade de las capacidades gráficas de la aplicación"...

Ya decía yo, El peso ejerce un enorme poder al momento de transmitir algo.... sobre todo si es el jefe superior quejándose de algo a los "mortales" que tiene por debajo en el organigrama

El español como idioma de desarrollo

Apenas entraba a la universidad y recuerdo los cientos de errores que Borland C me daba cuando creaba variables "castellanas": 'año', 'adición', etc. Entendí entonces que en lo que respecta al código, el español no es un idioma.. 'bonito', sobre todo por el hecho de tener que interpretar caracteres 'extraños'. Recuerdo también un consejo que decía "los libros de tecnología en español son una utopía, porque cuando llegan a ver la luz, ya la aplicación a la que se refieren, es obsoleta o tiene varios parches encima". Por todo esto pues, siempre me he acostumbrado a las versiones "inglesas" de las cosas: Sistemas operativos, IDE's, Suites de oficina, documentación, etc.


Es que verdaderamente, eso de "ir a Definición", no me cuadra mucho (a pesar de que es muy literal y fácilmente deducible de "go to Definition"). Pero hay conceptos que verdaderamente escapan a mi mente, como el porqué una persona instala aplicaciones en inglés y luego aplica parches de idioma.. cuando va a programar en un lenguaje pseudo-inglés...


Algunas cosas inevitablemente deben ser en español (He conocido sitios donde por política, el nombre de tus métodos debe ser en inglés, y en otros sitios, en español -aunque sin acentos y sin ñ- o en portugués). Usualmente, una de ellas es la documentación / Comentarios de código. Sin embargo pues.... colocarlos en inglés tampoco está mal (sobre todo si se trabaja en equipos con varias locaciones internacionales). Y verdaderamente tiene su ventajas trabajar en inglés, sobre todo el hecho de no tener que descargar paquetes adicionales de idioma (uno para Office, otro para Sistema Operativo, otro para el Framework).. y empiezas a acumular megas y megas de "paquetes" para simplemente poder leer "Archivo" en vez de "file"...

Tiene sentido esto?

Sobre la ética profesional

YO siempre he tratado de ser comprensivo con las personas, sus motivaciones y su forma de hacer las cosas. Espero no haber juzgado a nadie, ni haberle ofendido durante mis cortos 28 años de vida. Sin embargo, hay varias cosas que he observado, que me han afectado directamente y que me gustaría compartir.. y están relacionadas con ese sitio donde pasamos 9 hrs al día (incluyendo el almuerzo) de lunes a viernes...
Recientemente cambié de empleo. Nada fuera de lo corriente en esto. Las motivaciones de siempre. Al salir de la que fue mi empresa durante dos años, me tocó entregar el portátil que tenía asignado. 1 hr antes de entregarlo, procuré eliminar mis archivos personales, dejar todos los archivos y código fuente en repositorio compartido, verificar (de forma doble) que no tuviese archivos "sueltos", que todos los Login/passwords estuviesen en una hoja al momento de entregar todo, para que mi reemplazo o el que sea, pueda acceder de forma "libre" e "inmediata" a lo que fueron mis cosas. Reconozco que durante 2 años he instalado ciertos programas que aunque no estaban en la lista, me ayudaban a desempeñar mis funciones: Firefox, programas para comparar versiones y un laargo etc.
Sin embargo, en el nuevo empleo me he conseguido con un portátil, fuera de lo "estándar". Perteneció a otra persona, y como "logicamente" hubiese hecho, eliminó muchos programas que en principio no debieron estar ahi: clientes P2P (como Ares y eMule), MP3 y videos. Aun así, empleé un par de días en limpiar la compu de reproductores multimedias (VLC, QuickTime, VideoRa etc), Programas de transferencia de datos con Celulares/Moviles.
Entiendo que muchas personas guarden con gran recelo el "secreto profesional". Tal vez porque no soy 100% Microsoft y mas bien soy un anarquista, nunca me ha gustado llevarme el código fuente conmigo. Aquí hay un punto interesante: los pro-Software libre dicen "el código es de todos, distribúyelo", mientras que los de Software privativo.. no. Sin embargo, como programador del lado "privativo" entiendo que el código no es de mi propiedad, sino que es propiedad del cliente o de la empresa para la que trabajo. Y como tal, debo dejar constancia de ello (notificar al jefe o al "heredero" la ubicación de los fuentes, etc). Inclusive, siempre he sido un fanático de dejar todo comentado, estructurado, con explicaciones cuando el código es medio confuso. Pero.. que carajo, eso es lo que YO hago, porque a lo largo de 7 años de trabajo, he tenido buenos compañeros y maestros que me han dejado esas enseñanzas... pero creo que a no todos nos enseñan igual....