Mostrando las entradas con la etiqueta actualidad. Mostrar todas las entradas
Mostrando las entradas con la etiqueta actualidad. Mostrar todas las entradas

lunes, 20 de abril de 2015

Broken Culture

Los norteamericanos tienen una capacidad increíble para estandarizar cualquier realidad y encajarla en un set de historias prefabricadas, por más compleja que sea. Si, todo el mundo estandariza y encaja realidades en historias… es sólo que ellos lo hacen especialmente bien.

Mis feeds de “desarrollo” en inglés están llenos de telenovelas: los programadores somos la mucama inteligente, buena y fea; los managers, la malvada bomba sexy; la empresa (el capitalismo), el millonario que parece malo por estar atrapado sus redes pero que en el fondo es bueno. El final es cantado: la mucama inteligente se gana el corazón del millonario a fuerza de honestidad, bondad y trabajo duro, y en la última escena es la que está más buena de todas. La mala cae envuelta en sus propias telarañas y termina desenmascarada como la chupasangre inútil que es, desterrada en quién sabe dónde.

Tim Chevalier toma la decisión de abandonar la telenovela-sistemas y da sus razones. Después Michael O. Church sintetiza esas razones en una pregunta: “Can tech fix its broken culture?”, y responde “si” pero con más palabras. ¿Y cómo? Como dicta la trama: resistiendo los ataques del management-malvada-bomba-sexy y demostrando valía con honestidad, inteligencia y trabajo duro (y muy poca paga) hasta que el capitalismo-sociedad-millonario se de cuenta y expulse a los managers-malvada-bomba-sexy del juego.

La afirmación que más fuerte me suena en el post Michael no es “podemos reparar la cultura de sistemas”, sino otra mucho más desesperada y sutil: “hay una historia con un final feliz en el que los buenos que resisten son recompensados”.

En algún momento (allá lejos y hace tiempo) en el que hubiese coincidido (y hasta se podría buscar prueba de eso en este blog), un tiempo en el que lo “Agil” prometía ser la movida que desenmascararía las malvadas maquinaciones del management, demostrando de una vez y para siempre que los “techies” somos el verdadero corazón de las empresas.

Pero ahora, un par de años después, “Agil/Scrum” es más o menos lo mismo que “CMMI”. Todos los puntos de aquel manifiesto que hubiesen podido cambiar algo fueron ignorados o licuados; sólo quedaron las reuniones. ¿Y los tests y la integración continua y la nube y los frameworks y el open source…? ¿No son avances? Sí son avances… también las pantallas planas, los multi core, el wifi y los celulares… Pero el escenario es el mismo en el que se escribió The Mythical Man-Month (en 1975). Sólo cambió el decorado.

El argumento es “la mucama con esfuerzo llega al millonario”. En sistemas se dice “los techies programando van a dominar la industria”. El problema en la trama es “que la mala tiene al millonario engañado”. En sistemas, “que los managers son explotadores parásitos de la empresa”. Pero en ambos casos la industria/la empresa/el capitalismo siempre recompensa el valor generado. En última instancia verá quiénes generan el valor cuando los managers, a fuerza de incompetencia, caigan en su inevitable desgracia y se desencadene el final feliz.

En pocas palabras: hay que salir y mostrarle al mundo que los técnicos son los que generan valor. Siguiendo esa línea, si fuésemos adolescentes sobreexplotados de McDonalds deberíamos unirnos para revelarle al mundo que somos los que hacemos las hamburguesas.

Es una telenovela simplificadora que justifica lo que hacemos ante nosotros mismos mientras estamos dentro. Nos convence de quedarnos y nos explica por qué se van los que se van, separándonos de ellos para que no se nos ocurra tomarlos de ejemplo. “Cualquier parecido con la vida real”, lejos de ser casual, ha sido elaborado, refinado y corregido a lo largo de los siglos (si, siglos: Cenicienta) para identificarnos con la mucama-pobre-heroína de la trama mientras hacemos girar la rueda del molino, caminando en círculos hacia ninguna parte.

Como las telenovelas, es un discurso que no tiene ni pretende ser real ni tener sentido, sólo coherente y útil hacia dentro. Si uno rompe “la cuarta pared” y abandona el set ya no ve ni buenos ni malos ni lindos ni feos ni historia ni nada: sólo un montón de actores representando un guión más o menos delirante que no escriben ni escribieron.

Bueno, y “Can tech fix its broken culture?”

La “cultura de las empresas de tecnología” no está rota. La “cultura de las empresas” surge y prospera en tanto las hace funcionar, sobrevivir y prosperar… a las empresas, no a las personas. No está ahí para conseguir la felicidad ni el bien común de nadie… pero tampoco para impedirlos.

Personalmente creo que no hay nada que demostrar ni a quien demostrarle nada; nadie mirando, sólo nosotros mismos. No hay héroes buenos-pero-feos enfrentados a managers-malos-que-parasitan-las-empresas, ni millonarios naive a los que hay que llevar por la buena senda para bien de todos. Ni siquiera hay un “somos” ni un “son”: no hay una historia común encaminada hacia un final feliz, o hacia ningún otro lado. Lo que hay es un momento y un espacio y ciertas reglas más o menos fijas… A algunos les conviene el status quo, a otros no. Para los que no, a veces se puede y vale la pena dar la pelea por el cambio, a veces no.

De lo que estoy más seguro es de que no se toman buenas decisiones mirando telenovelas.

sábado, 30 de agosto de 2014

Mi aplicación

Casi todos (los programadores, obvio) tenemos “mi aplicación”. Ésa que, cuando haya tiempo, vamos a hacer “como se debe”.

El “como se debe” varía con cada uno, pero me arriesgo a generalizar: no es una afirmación positiva sobre ciertas herramientas y prácticas, es más bien una negación de aquellas que venimos utilizando, utilizamos o nos obligaron a utilizar, o de las que escuchamos hablar mal por ahí o… un largo etcétera.

En criollo: “mi aplicación” no va a ser como éste proyecto-huérfano-engendro-mutante del que me contaron, caí o armé (“por culpa de…”, seguro).

¿Cómo es “mi aplicación”? La mía de mi propiedad, al día de hoy, es:

-Una aplicación web hosteada en google.

-Server side: en java, pero va a devolver exclusivamente JSON. Pura data. Lo juro.

-Con alguna base de datos no relacional, porque son re-cool.

-Bootstrap.

-Pero no pienso escribir una sola regla de css. Lo juro.

-Ni tampoco mucha imagen ni iconito. Si puedo quedarme sólo con lo de bootstrap, mejor.

-Ni meterle 10.000 plugins (aunque ya empecé… pero lo voy a deshacer, y cuando lo deshaga lo juro).

-Jquery

-Jquery validation, si hace falta (imagino que sí).

-Knockout.

-Require.

-Y visjs, porque necesito algo así.

-Y NADA más.

El problema es… el de más arriba: que es cuasi-simétricamente-opuesto a todo lo que alguna vez hice: no soy diseñador ni mucho menos (estoy aprendiendo que entre “seguir la onda”, y “diseñar” hay un abismo insondable). Nunca programé en java (profesionalmente, proyectitos de prueba hicimos todos). Nunca usé bootrstrap. De íconos y gráfica o imágenes… sólo sé buscar en google, y al photoshop no me lo presentaron (ni siquiera sé usar bien el paint.Net). Visjs es genial, pero todavía estoy leyendo la documentación. Los únicos viejos conocidos son Knockout, require, jquery y compañía. Pero son herramientas, no una forma de trabajar con la que uno viene acostumbrado, y en la que “el camino para hacer tal cosa” aparece casi naturalmente.

Como todo primer intento, es… bueno, como se imaginan que es. Pero hay que seguir haciendo y rehaciendo hasta que salga. Mentalmente, claro, porque en la real realidad, uno va dedicándole horas a cuentagotas entre proyectos más rentables, con la esperanza de que en algún momento éste también lo sea.

Si bien “construir éste sistema lo antes posible” es la madre de todas las cag…, también es la madre de todas las cosas que están ahí afuera en este preciso momento, satisfaciendo necesidades de éste preciso momento, probablemente tan efímeras como la combinación de herramientas que (ahora) “me gusta”.

“Como a mí me gusta” va variando a medida que avanzamos. A veces más, a veces menos, pero siempre, con cada paso hacia adelante, surge el imperioso impulso de pasarle la guadaña a (casi) todo lo que se deja atrás… y uno va y lo hace. Porque ésta es “como a mí me gusta”. Es inevitable: la motivación parte de “armar un proyecto como a mí me gusta”, y no “construir éste sistema lo antes posible”.

Pero bueno, juntar dos o veinte librerías, copypastear un poco de código y salir con algo rápido a ver si pega es, probablemente, eficaz. O por lo menos un fracaso rápido y a otra cosa… pero no es lo que tengo ganas de hacer ahora.

Tengo ganas de seguir jugando.

Y a todo esto… ¿qué hace, exactamente, “mi aplicación”?

Por ahora, nada.

¿Qué debería hacer?

No está muy claro, ya veremos. Lo importante es que “esté como a mí me gusta”.

¿Verá la luz del sol?

jueves, 10 de septiembre de 2009

Estar en la pomada.

No tiene nada que ver con lo que iba a escribir, simplemente me dio curiosidad el origen de la expresión, y aquí va:

Cuenta la leyenda que hace siglos, en Bretaña los soldados partían a la batalla numerados. Cada guerrero exhibía un pendón con un determinado número de manzanas […]

Llegados tiempos de escasez, entre otras muchas cosas empezó a faltar el ungüento con que se curaban las heridas de los guerreros a su vuelta del combate, de modo que se decidió usar la clasificación de la pomada para ver quién tenía derecho a que sus heridas fueran curadas con el escaso ungüento […]

De este modo, se generalizó primero la expresión estar en el ungüento, que, posteriormente, cuando el grupo de pendonados con manzana pasó a ser conocido como la pomada, quedó como estar en la pomada, como sinónimo de estar en el grupo de los primeros clasificados.

(extracto del blog infulas)

Aclarado el punto (mucho más interesante que lo que sigue, por cierto) voy a la pequeña reflexión que lo motivó: desdesarrollo está en su máximo de visitas, pegando un interesante salto respecto del mes anterior.

Tan interesante ha sido el susodicho que me he puesto a revolver el analytics con un poco más de obsesividad que de costumbre en busca de su origen.

Quería corroborar que, encantados con mi prosa, inteligencia y capacidad analítica (e ironía), los lectores caían en masa.

Finalmente no me ha quedado otra que enfrentar la verdad: la causa ha sido la aparición de ciertas palabras en los títulos, palabras que han atraído especialmente la atención de google. La marea no es de lectores sino de buscadores, y de ellos una ínfima parte pasa más de 5 segundos en el blog.

Somos, en definitiva, más o menos los mismos de siempre. La única diferencia es que en vez de estar charlando en una esquina de pueblo lo estamos haciendo en medio de una concurrida estación de trenes.

¿Qué es lo que ha transformado aquella esquina solitaria en este concurrido lugar de paso? Las palabras han sido, no muy soprendentemente: “jQuery” y “AJAX” (de la serie Ajax: C# .Net 3.5 + jQuery).

Qué mejor indicador de cuáles son las tecnologías que hay que dominar para estár “en la pomada” hoy en día que el  constante crecimiento de las búsquedas que se realizan alrededor de jQuery:

Cada vez me convenzo más de que el futuro de la web (y de la mayoría de las interfaces de usuario) será escrito en javascript.

miércoles, 9 de septiembre de 2009

Web vs. Desktop.

battle  La eterna batalla, la eterna duda: ¿Debería ser una aplicación desktop o un servicio web? Para mí no hay dudas: allí donde una conexión entre cliente y servidor esté disponible, web, y no se hable más. Pero es sólo una opinión de programador fundada exclusivamente en mis gustos y preferencias a la hora de construir el software.

Acabo de leer el largísimo (y sin desperdicio), muy recomendable post Why I’m Done Making Desktop Applications, donde el autor compara no sólo los resultados técnicos sino también los económicos y comerciales entre las versiones web y desktop de su aplicación.

A modo de resumen, y para tentarlos a seguir hacia el artículo original, enumero las razones que expone Patrick para su nueva preferencia por las aplicaciones y servicios web:

  • The Shareware Funnel Is Lethal: el camino que debe atravesar el posible cliente hacia la compra es largo y penoso (una frase inspirada acerca de la instalación: “Click through six screens that no one in the history of man has ever read”).

  • Web Applications Convert Better

  • Your AdWords Strategy Is Very Sensitive To Conversion Rates

  • Web Applications Are Easier To Support

  • The Age Of The Pirates Is Coming An End, Jack

  • Phone Home vs. Google Analytics

  • Web Apps Can Be Customized Per User

  • Long Cycles Mean Low Innovation.  Short Cycles Mean Fast Innovation

Cada punto está muy bien expuesto y las razones sólidamente fundamentadas. Vale la pena leerlo en profundidad para beneficiarse de la experiencia de quien ya ha dado el salto. Link:  Why I’m Done Making Desktop Applications.

domingo, 6 de septiembre de 2009

El estilo, la legibilidad, los “malos” programadores y el ¿diabólico? codebehind en el Microsoft .Net MVC.

Antes que nada: si usted, querido lector-programador de .Net, no tiene y/o no quiere tener nada que ver con el .Net MVC de Microsoft siga leyendo de todas maneras, que la cuestión va mucho más allá de eso y es interesante.

Los hechos.

El hecho es que en el .Net MVC de Microsoft, las vistas no tienen codebehind. En realidad no es que no tengan o no puedan tener, sino que por defecto no lo tienen, siendo el estilo de codificación sugerido para las vistas más o menos como lo muestra esta imagen:

MVCview

Es decir, utilizamos los viejos y conocidos tags <% %> para escribir código C# inline en medio del aspx, el javascript y el html. Los controles del lado del servidor (TextBox, CheckBox, DropDown) han sido reemplazados por un helper que utilizamos para no escribir un montón al implementar tareas comunes (como ponerle un valor a un input type=text) pero que es sólo eso, un helper.

Las opiniones

La verdad que es un cambio importante en la forma de pensar y escribir una página web en .Net. Personalmente a mí me ha costado muchísimo adaptarme (y, les adelanto, me he dado por vencido y vuelto al codebehind). Indagando un poco sobre este tema me encontré con que, obviamente, no soy el único.

Pero vamos a las opiniones, y primero las que están en contra (del codebehind): Steven Smith, comentando la reaparición del codebehind en las próximas versiones del framework, dice en su blog que, lisa y llanamente, Codebehind Files in ASP.NET MVC are Evil. Steven no es ningún improvisado, hay que pensar en sus razones (el resaltado es mío):

The problem with having a codebehind file for a View comes down to temptation and habit.  If it's there, anybody who's been using "classic ASP.NET" for the last 8 years or so is accustomed to putting all kinds of things into the ASP.NET codebehind files.  From click handlers to Page_Load to event wireups to changing display settings based on the value of a data item - most web forms apps have a ton of logic in their codebehind files.  And that's great - but not typically how it should be done with ASP.NET MVC.

[…] If having the codebehind file available by default is a temptation to stray from the canonical correct MVC path, then not having it there by default would help most developers do things the right way without thinking about it.

Encontré, en el mismo set de resultados en google, una respuesta de Luis Abreu posteada en su blog en una entrada titulada (obviamente) Codebehind files in ASP.NET MVC *ARE NOT* evil (el resaltado es mío).

Before going on, I understand Steve’s point of view: keeping the codebehind files might lead you to put code that belongs to the controller on the view. As I said, I understand, but I want to believe that a good developer will understand MVCs strenghts and will, after some time, have no doubts on where some behaviour (code) should go.

On the other hand, I’m not sure that removing the codebehind file will be enough for stopping a “bad” programmer […]

Luis tiene un sueño, que yo comparto:

Let me share with you a dream which makes me stick harder with the “pro-codebehind” approach […]

Imagine seeing no more of those <% %> floating everywhere on your aspx page…having a clear separation between markup and code, which doesn’t happen with the current view engine. If you want to really imagine it, just compare the old spaghetti ASP code with the elegance of the ASP.NET web forms page but don’t think about events and view state…just concentrate on the markup. Now be honest: do you preffer the spaghetti or the web form’s approach […] ?

Yo mismo no lo hubiese expresado mejor. Pero esa es mi opinión, es hora de comenzar otra sección.

Mi punto de vista 1: la estética.

Si hay algo que no me gusta en cuestiones de arquitectura (y de desarrollo de software en general) son las opiniones categóricas: “los tags <% %> son el demonio”, “el codebehind es el demonio”, “todo el sql debe estar en la base de datos”, “los parámetros opcionales son el demonio”, “los objetos no deberían tener propiedades”… un largo etcétera. Me parece que se confunden directivas de diseño con reglas inmutables escritas en piedra, tiendo a pensar que el que las pronuncia no está pensando en la situación actual y real del día de hoy sino evadiéndose hacia un mundo perfecto donde la arquitectura y las necesidades son la misma cosa.

Yo soy más del estilo de aquellos Principios de Diseño de Guido van Rossum que publiqué en uno de mis primeros posts. Voy a traer a colación los que me parecen relevantes:

  • Hermoso es mejor que feo.
  • La legibilidad cuenta.
  • Los casos especiales no son suficientemente especiales como para romper las reglas…
  • Aunque lo pragmático gana a la pureza.

No hay absolutos, hay momentos en los que hay opciones, herramientas entre las que hay que elegir, ventajas y desventajas. Con Rick Hunter (más que experimentado arquitecto) solíamos terminar este tipo de discusiones con la frase “no nos queda otra… hay que pensar”. No queríamos pensar, queríamos una regla mágica que nos solucionara la vida… si existe la verdad es que nunca la encontramos.

Volvamos al caso. Piensen en los cuatro puntos de Guido, recuerden –si es que han trabajado con él- ASP 3.0. Ahora vuelvan a mirar la imagen de arriba e imaginen esa sintaxis en la implementación de una página realmente compleja. Las interfaces de la vida real son complejas, los usuarios quieren interactividad, quieren ver lo que pasa cuando cambian valores, quieren cosas que llamen la atención sobre los errores lo antes posible, no son un formulario en el que el tipo introduce datos, aprieta un botón y se va a su casa.

Yo veo un infierno de colores en el que se mezclan C#, markup de .Net, html, javascript, y cuanta cosa se nos ocurra meter en una página web. Por cierto, Guido también dice:

  • Disperso es mejor que denso.

Yo creo que sería mejor tener todos esos lenguajes separados que revueltos e interactuando juntos en el mismo lugar.

Mi punto de vista 2: los “malos” programadores.

Steven Smith le teme a los inexpertos, a los viejos y a los malos programadores (todos les tenemos miedo). Respecto de los primeros, siente que nunca abandonarán .Net “tradicional”, y que si abre esa puerta van a implementar toda la funcionalidad en la vista, dejando los controladores vacíos. A los últimos quiere obligarlos a hacer las cosas bien.

Eso es imposible. Un mal programador hará las cosas mal (no “más fácil” o “más difícil”, sino simplemente mal) independientemente de dónde esté picando código. Y eso es inevitable. Si hubiese una forma de forzar a un programador a hacer bien las cosas, entonces su trabajo sería reemplazable por una herramienta automática, y por lo tanto inútil… en general no es ése el caso.

El “malo”, ya lo dije, es incorregible y sólo podemos alejarnos de él o a él de nosotros. Al resto, a los inexpertos o a los “viejos” que vienen de otras tecnologías basta con mostrarles que es mejor separar la lógica entre vista y controlador, seguirlos, corregirlos, darles las herramientas y los criterios para elegirlas.

No creo que el objetivo un framework sea el control o la restricción. Su objetivo es estructurar, proponer un orden, facilitar el desarrollo, no impedirlo. Un buen framework no es aquél en el que no se puede programar mal, sino aquel en el que que programar bien es más fácil.

Mi personalísima conclusión

Volviendo a MVC: yo voy a cambiar los <%=Html.Input(…)%> por controles, y a agregar el codebehind para establecer sus valores e implementar la lógica de presentación en forma separada del html. Porque es más prolijo, más lindo, tal vez disperso pero mejor que denso, tal vez más complejo, pero mejor que complicado.

¿Y a uds. qué les parece?

jueves, 11 de junio de 2009

Crisis, ajuste, motivación, productividad, oportunidad.

Corren tiempos de crisis. Traducido al argentino esto implica, aunque sea implícitamente (vía inflación, que aquí el que no corre vuela y el margen de beneficio a corto plazo se valora incluso más que la supervivencia), “ajuste” de salarios. Escribo “ajuste” y no ajuste porque con el entrecomillado pretendo denotar que “ajuste” no es ajuste sino un eufemismo para baja que suena feo. Y es baja y no “congelamiento” o “suspensión de aumentos” debido al pequeño detalle de la inflación mencionado más arriba.

Pero bueno, es lo que marca el mercado y si el golpe de la crisis se distribuye justa o injustamente entre capital y trabajo (o la suposición de que justicia y economía están relacionadas de alguna manera) no es el tema de este post.

Por otro lado, en la industria del del software (y supongo que en cualquier otra cuya base esté mayormente conformada por trabajadores del conocimiento) motivación y productividad están fuertemente relacionadas, si es que no son la misma cosa (¿podría decir que está motivado un programador que no produce? ¿por qué otra razón que no sea falta de motivación podría no producir un programador? Es decir, el que está motivado llega a un resultado, que puede no tener un gran nivel o calidad, pero producir produce).

Mi hipótesis es que si el mencionado “ajuste” afecta a la productividad en esta industria es -por lo menos principalmente- a través de esta forma indirecta, por su impacto en la motivación.

Es un buen momento para recordar aquello de que el motivador más caro es el dinero (creo que es una frase célebre pero no puedo encontrarla, tal vez esté formulada de otra manera). Es por ello que me cuidé de escribir que el ajuste “afecta” a la productividad y no que la disminuye o aumenta, ya que la productividad depende de la motivación y la motivación no necesariamente del dinero.

Me parece una explicación bastante sencilla de por qué hay emprendimientos o proyectos en los que la productividad aumenta considerablemente en tiempos de crisis: hay ajustes monetarios pero la motivación, y por tanto la producción (el desarrollo) se mantiene (o incluso aumenta) y la productividad (la relación entre recursos utilizados y avance obtenido) mejora.

Y también de por qué hay otros proyectos que florecen velozmente una vez pasada la tormenta: si el aumento de productividad es en la práctica una mejora en el proceso de desarrollo el proyecto actúa tal cual un resorte que absorbe el impacto primero e impulsa al equipo, empresa, organización o producto cuando la crisis pasa.

Y de por qué otros proyectos, incluso sobreviviendo a la crisis, no logran volver a ser lo que eran. Hay un punto en el que la motivación cae de tal manera que luego (parafraseando a un gran amigo) “a esto no se lo levanta ni con plata”.

Ejemplo un poco burdo: imaginemos tres equipos enfrentados a la misma crisis. En la práctica (aparte del “ajuste”), lo que sucede es que faltan horas/hombre de analistas funcionales para las pruebas, que el recurso de las horas extra está agotado (es decir, los actuales analistas están agotados) y que no hay posibilidades de contratar más.

  • Equipo I: no hay respuesta. El equipo hace lo que siempre hizo: programar y punto. El proyecto se atrasa, el producto no mejora, se codifica pero no se prueba y las modificaciones no salen, etcétera. Para cuando pasa la crisis hay un retraso importante respecto de la tecnología y de los competidores que han sabido aprovechar o por lo menos capear el temporal.

  • Equipo II: el equipo pone el hombro y se pone a probar. No son buenos probando pero hacen lo posible y la productividad sufre pero las cosas salen. Si pasa la crisis se vuelve al ritmo normal, y tal vez con más recursos se logra recuperar el tiempo perdido, aunque con gran esfuerzo extra.

  • Equipo III: no se resignan a producir menos ni a trabajar más, por lo que buscan la forma de trabajar mejor. Así que buscan la forma no de cubrir las horas faltantes sino de requerir menos horas de pruebas. Descubren (imaginemos que no las conocían) las bondades de la programación orientada al test, herramientas para automatizar tests unitarios y funcionales, reducen costos con máquinas virtuales, programan simuladores de componentes y un largo etcétera. Para cuando la crisis pasa están mejor parados que al principio y cuando se recuperan los recursos éstos se utilizan para hacer más que antes logrando una gran expansión sobre un mercado depurado de competidores.

¿Cuál habrá sido el nivel de motivación en cada equipo antes de afrontar la crisis? ¿Y al final?

martes, 19 de mayo de 2009

1984

Puede que George Orwell (antes de empezar permítanme decirles que si no han leído 1984 han aprendido a leer para nada) haya cometido apenas un pequeño (en proporción) error con las fechas, después de todo. Digamos unos 30 años. O menos.

Pensaba en eso después de leer esta nota en público.es, de la que transcribo (qué viejo suena eso. Corto y pego, digamos) el primer párrafo:

Hace 24 años, Ivana P. cometió un delito por el que fue condenada y posteriormente indultada. Sin embargo, esta madrileña aún está pagando aquella deuda. Los detalles de los hechos por los que la condenaron aparecen relatados en la web del BOE, y después han sido clasificados en Google, el buscador que utiliza más del 90% de los internautas españoles. Aunque esta mujer ha presentado varias reclamaciones, la web sigue trayendo al presente aquella historia de hace casi un cuarto de siglo.

Orwell imaginó un Gran Hermano omnipresente y controlador. Puede que el ¿futuro? sea apenas sutilmente diferente.

Si bien es cierto que la red nos ofrece anonimato no es menos cierto que la línea entre el espacio público y el privado es, en algunos casos, confusa (claro ejemplo: Facebook), y en otros difusa.

Dejemos por un momento de lado los casos en los que los problemas puedan adjudicarse a la torpeza o ignorancia del propio navegante afectado. Son cada vez más los registros públicos por naturaleza -tales como las sentencias de los jueces- fácilmente rastreables vía buscadores. Se va conformando, con el paso del tiempo, el avance de la digitalización de la información y su anexión a la red, un gran repositorio (internet, no Google) que todo lo recuerda y todo lo publica.

Somos (y seremos cada vez más) conscientes de que teniendo disponible una memoria tan poderosa se nos cobra caro hasta el más pequeño desliz. Podría ser en el fondo de una foto inocente tomada durante una salida y publicada en el perfil de una amistad donde la señora (futura ex) encuentre por casualidad al marido peligrosamente cerca de la (futura ex) mejor amiga… un par de años después del incidente inmortalizado en unos y ceros (que, imaginemos, no pasó de una indiscreción inducida por el alcohol).

Lo que hacemos en público es público. El marido de la historia anterior poco tiene que reclamarle a Facebook sobre la desgracia de su matrimonio. Poco -creo yo- tiene que reclamarle Ivana P. a Google o al BOE la distribución de información absolutamente correcta (y pública por naturaleza), por más que afecte su vida cotidiana.

Una línea difusa… ¿y lo que hacemos en privado y es ventilado por algún torpe, indiscreto o vengativo observador? Pregúntenle si no a… (no voy a volver a cometer la torpeza de escribir otra vez ese nombre, por más visitas que genere).

El hecho objetivo es que, en público o en privado, cada vez hay más ojos alrededor nuestro, inocentes o no. Ojos que no sólo ven sino que también recuerdan. El hecho objetivo es que esa información, una vez liberada, es muy difícil de destruir.

¿Llegaremos al punto en el que la amenaza de una exposición descontrolada pese lo suficiente como para reprimir hasta el más mínimo atisbo de cualquier conducta que pudiese calificarse negativamente en el presente o el futuro? ¿Llegaremos al punto de sentirnos siempre observados y continuamente juzgados por lo que hacemos y decimos y por lo que hicimos o dijimos? ¿Presos de por vida en nuestras propias palabras y acciones pasadas?

Orwell imaginó un Gran Hermano, pero parece ser que nadie puede controlar, encauzar o reprimir el flujo de información en la red. El archivo afecta tanto a gobernantes y empresarios poderosos como a ilustres desconocidos.

Así, Gran Hermano, el gran represor, lo conformamos todos al juzgar socialmente y tomar decisiones basadas en esa información. ¿Sufre Ivana P. las consecuencias de la publicación de una condena o el hecho -innegable- de que pocos avalan con hechos la opinión expresada de que quien ha cometido un crimen puede (y merece) pagar sus deudas y vivir una vida honrosa de allí en más? ¿El marido porque la mujer ha descubierto esa foto o la imposibilidad -de ambos- de reconstruir la relación luego de eso? ¿Sufre el joven por la aparición de una foto que lo muestra pasado de copas o por el prejuicio del empleador que infiere de ella que es una persona poco seria (y que opina que la competencia va de la mano de la seriedad)?

Si, como decía antes, errare humanum est, tal vez deberíamos preocuparnos menos por la disponibilidad de la información histórica acerca de grandes y pequeños errores y momentos poco afortunados que por la interpretación y el uso que cada quien hace de ella.

Si encontrar cierta información sobre una persona en la red nos parece escandaloso deberíamos pensar por qué, qué esperábamos encontrar, y qué nos dice el hecho de que la estemos buscando (y las decisiones que tomemos en base a ella) sobre nosotros mismos y nuestros propios prejuicios.

lunes, 18 de mayo de 2009

WolframAlpha

No sé qué tan útil sea el chiche nuevo de Stephen Wolfram, WolframAlpha, habrá que usarlo más que probarlo. Mientras tanto algunas primeras ideas alrededor de él:

  • No es un buscador. Llámenlo como quieran, pero no es un buscador.

  • Más bien pretende ser el sistema experto definitivo.

  • Tampoco creo que esté para o vaya a revolucionar nada.

  • De todas maneras la idea es estupenda y muy bien ejecutada.

  • Sí compite con Google aunque no directamente. Yo utilizo mucho a Google para buscar datos concretos y supongo que muchos harán lo mismo. WolframAlpha brinda respuestas directas (cuando las tiene) de una manera mucho más sencilla y categórica, está específicamente diseñado para eso. Google también cubre muy bien la misma necesidad aunque haya que buscar entre los resultados e interpretarlos. Si WolframAlpha se desempeña bien se quedará con esa tajada del tráfico (que no tengo idea de qué tan grande será, pero supongo que bastante).

  • Se ha desarrollado una gran campaña previa y generado mucha expectativa. Es un arma de doble filo, pero creo que en este caso la herramienta supera la primera impresión… bueh, depende (de si el usuario es argentino o español, por ejemplo), pero en general lo hace. De todas maneras hay que chequear los resultados.

  • Se ve que el equipo tiene muy en claro a qué público debe conquistar primero (ver imagen):

wolfram

Actualización: acabo de leer un muy buen comentario, Wolfram's Black Box: a biologist's take on Wolfram|Alpha, por John Timmer.

martes, 14 de abril de 2009

Sistemas administrativos, software, avances, cambios, revoluciones.

 problemassolucion

Encontré la imagen que ilustra este post en Acceso Directo (que a su vez lo vio en Abadía Digital, que lo sacó de Digg… ¿es que nadie dice nada nuevo ya?). Viene muy a cuento de lo que estaba escribiendo, que es lo que sigue:

Es un camino posible para los proyectos de desarrollo de sistemas (de soporte a la gestión en las organizaciones) el que se inicia con trabajadores de las distintas áreas (futuros usuarios) comentando con un analista funcional el recorrido de la información en los diferentes procesos en que participan. Es un camino que continúa con el analista transformando esa información en especificaciones (tal vez haciendo algunas recomendaciones de cambio al cliente), alguien modelando una base de datos, programadores codificándolo en forma de formularios, validaciones, autorizaciones, un sinfín de ajustes, problemas menores y mayores, retrasos… Sigue luego de la instalación con caídas y recuperaciones varias, más ajustes y un final feliz para todos… algunas veces. Es el camino del desarrollo a medida.

En el otro extremo de un amplio espectro de relaciones posibles entre el cliente y el equipo de desarrollo, otro camino comienza más o menos igual, en esa famosa charla entre analista y usuario. Pero luego es el analista el que indica las adaptaciones al recorrido de la información necesarias para la implantación del software. Sigue con la capacitación a los usuarios, la implantación del software, migración de datos… y termina más o menos igual que el anterior, con caídas y recuperaciones varias, más ajustes y un final feliz para todos… algunas veces. Es el camino de la adopción de un sistema de software “enlatado” (ya sé, no es enlatado exactamente pero para el caso está bien, no seamos muy estrictos con los términos).

Esos son dos extremos, obviamente teóricos (o por lo menos muy poco frecuentes), de una escala absolutamente arbitraria creada al sólo efecto de poner en tema al lector de este artículo.

Lo que ubica a todo desarrollo de la vida real en algún punto intermedio de esa escala es una negociación entre cliente y proveedor que tiene lugar en algún punto o a lo largo de todo el proceso previo al desarrollo propiamente dicho. En ella se establece en qué aspectos se adaptará el recorrido de la información en la organización a las necesidades específicas del proveedor del sistema y en qué otros aspectos se adaptará el proveedor del sistema a las necesidades o caprichos del cliente.

Lo que es seguro es que el resultado final -en términos de circuitos administrativos- no se apartará demasiado del original del cliente (en un extremo) o del implementado anterior y repetidamente por el proveedor (en el otro). Tampoco será sustancialmente diferente al que gente de sistemas como yo, analistas, programadores, administradores, contadores, ingenieros y demás profesionales hemos aprendido en la facultad o a través de la experiencia.

Finalmente, y para resumir, la organización termina haciendo más rápido (mucho más rápido) más o menos lo mismo de antes o pareciéndose (usualmente para mejor) a todas las demás en el mercado.

Con lo que volvemos a la imagen que ilustra todo esto. Hemos resuelto efectivamente el “problema”. Hemos reducido costos y personal, acelerado los procesos administrativos, optimizado tiempos y recursos… todo mejor y más rápido y sin embargo, por debajo de todo eso, persisten los mismos problemas que enfrenta la administración… porque nada ha cambiado realmente todavía.

Que no se entienda lo anterior como una queja, que no lo es. A lo que apunto es a esto: la tecnología ha revolucionado nuestra vida y sociedad en muchos aspectos. Hoy la mayoría de las organizaciones cosechan el fruto de esta revolución en forma de un aumento en la velocidad, alcance y menores costos de funcionamiento de sus circuitos administrativos. Este aumento no ha sido lineal sino exponencial, por lo que los cambios han sido profundos. Pero en este aspecto (el de los circuitos administrativos en las organizaciones) no podemos hablar de revolución, por lo dicho anteriormente: las organizaciones siguen funcionando más o menos como antes.

Creo que en el transcurso de nuestras vidas este “cambio” se transformará en una “revolución”. Comienzan a surgir nuevas formas de organización. Formas de organización que no “aprovechan”, sino que tienen origen en las posibilidades inherentes a la tecnología de la que disponemos ahora y de la que no disponíamos antes, marcando una diferencia cualitativa.

Proyectos de software colaborativos, Wikipedia y demás wikis de todo tipo, comunidades creadas alrededor y a través de determinados servicios o soportes como Facebook, Twitter, Digg… toda esa (aunque no solamente esa) cosa “2.0”.

Es un comienzo. En definitiva todos esos proyectos, empresas o comunidades/servicios que mencioné se apoyan o son en alguna medida organizaciones “comunes” con un lado “tradicional”. Pero creo que tienen el potencial de generar algo diferente. Diferente y seguramente también ajeno a ellos mismos. Algo revolucionario.

¿Nuevos recorridos para la información? ¿Ningún recorrido en absoluto, un especie de caos acotado y dirigido hacia determinado objetivo? ¿Organizaciones sin objetivos concretos propios? ¿Organizaciones con un objetivo amplio (beneficio económico, por ejemplo) y sin reglas formales establecidas? ¿Con wiki-reglas que pueden hacerse y deshacerse, que “todo el mundo puede editar”? ¿Que un sistema implementa automáticamente en forma de circuitos cambiantes? ¿Organizaciones que se generan espontáneamente y que desaparecen tan rápido como se crearon, también espontáneamente? Quién sabe.

lunes, 6 de abril de 2009

Entre la formación y la realidad.

Creo que hay una gran brecha entre la orientación que brindan las distintas carreras de sistemas y la realidad del mercado del desarrollo de software, por lo menos aquí en Buenos Aires y con respecto a la UBA (la Universidad de Buenos Aires, que es la universidad pública, gratuita y –por lo menos para las carreras que nos ocupan- de acceso irrestricto).

IMHO, por un lado el mercado requiere programadores para satisfacer una demanda creciente (incluso en estos tiempos de crisis) de desarrollo, mantenimiento (sobre todo), adaptación o implantación de sistemas de gestión de la información. Sistemas de pago, de facturación, de cuentas corrientes, de control de la producción, etc., y cada vez más orientados a negocios o rubros específicos (panadería, gestión de un taller mecánico, de una tienda de ropa), donde pequeñas empresas o equipos de desarrollo y profesionales independientes encuentran un nicho al que no pueden llegar los sistemas más conocidos como SAP o Tango (supongo que sólo tiene vuelo local, pero es muy conocido aquí).

Desde el punto de vista de la programación o codificación estos sistemas no son muy complejos… de hecho no son complejos en lo absoluto. Como se mencionaba hace algún tiempo en ¿Aburrido?, básicamente existe una base de datos que representa objetos y transacciones de la vida real, un software que materializa en múltiples pantallas de ingreso las reglas que indican cómo y cuándo esa información puede ser actualizada y un montón de reportes a través de los cuales es distribuida a través de la empresa o, hablando más en general, la organización.

Cada sistema tendrá algunas funcionalidades únicas (si no es así probablemente esté condenado al fracaso) o problemas particulares que representarán un verdadero desafío, pero no suelen representar más que un pequeño porcentaje de la funcionalidad total, y muchas veces son extras más orientados a diferenciarlo en la venta que al uso real y cotidiano.

El éxito o fracaso de un proyecto dependerá, más que de la pericia o ingenio de los programadores para crear algoritmos complejos que resuelvan problemas complejos, del conocimiento que posean, tanto éstos como los analistas y líderes del proyecto, del negocio que están modelando.

Este conocimiento tiene más que ver con facturas, recibos, remitos, balances, arqueos, tickets, inventario, impuestos, control de costos y esas cosas que con optimización, índices, grafos, métodos de ordenamiento, operaciones por ciclo de máquina, lenguajes, compiladores.

Eso por el lado del mercado.

El problema es que, del lado de la formación, las carreras de sistemas con contenido de programación poco y nada tienen que ver con el mundo de los negocios, y viceversa. Esa fue siempre mi sensación. Para este artículo estuve haciendo un poco de investigación tratando de verificarla o refutarla.

De las carreras de grado de la UBA, las que tienen algo que ver con sistemas son:

Más o menos a ojo (espero no haber pifiado mucho, si alguno de ustedes es o fue alumno de esas carreras me gustaría conocer su opinión al respecto), por los nombres de las materias, se deduce que:

  • Para Análisis de Sistemas (Fc. de Ingeniería, 1739 alumnos) el 27% de las materias están orientadas a la programación propiamente dicha, y sólo el 7% tiene que algo que ver con lo administrativo, lo contable o la gestión de una organización.

  • En Ingeniería en informática (Fc. de Ingeniería, 3194 alumnos), la programación ocupa entre el 26 y el 33%, contra un 4%, 2% y 15%, con la salvedad de que éste último porcentaje corresponde a la Orientación en Sistemas de Producción, por lo que imagino que estará enfocado a esa área.

  • En la Licenciatura en Ciencias de la Computación (Fc. de Cs. Exactas, 1573 alumnos), los porcentajes son 38% contra… 0%. 38% para el lado de la programación, por supuesto. Debe ser duro para un egresado de esta carrera enfrentarse a un ERP o a un CRM armado sólo con lo que la universidad le ha enseñado.

  • En la Licenciatura en Sistemas de Información de las Organizaciones (Fc. de Cs. Económicas, 1566 alumnos) nos encontramos que el estudio acerca del funcionamiento de la organización ocupa el 29% de la carrera (menos mal, ya que es de la Facultad de Ciencias Económicas), pero la programación sólo un 12%.

Pueden consultar la lista de materias (fuente oficial aquí, siguiendo el vínculo de cada carrera), cuáles conté para uno y otro lado y cuáles dejé afuera, aquí. La cantidad de alumnos proviene, desgraciadamente, del Censo de Estudiantes 2004, que es el último disponible (ese vicio tan habitual en la cosa pública Argentina, de ir a ciegas por la vida).

Es obligatorio aclarar que esto no dice nada acerca de la competencia de los profesionales que egresan de esas facultades (habrán buenos y malos en todos los casos). La experiencia aporta el resto y si hay algo que hace (en mi opinión) a la UBA una de las mejores universidades (seguro que de Argentina y puede que de Latinoamérica) es que sus alumnos salen con una innegable capacidad de seguir aprendiendo y enfrentarse a nuevos problemas, gracias también a que el resto de la plantilla brinda un conjunto de herramientas teóricas de carácter general que el profesional puede adaptar a su situación específica. Finalmente unos tendrán que aprender qué es eso de la partida doble y otros qué es una lista doblemente enlazada, si es que lo necesitan.

Se me dirá que se requiere de profesionales de más de una de esas carreras para completar un equipo. Cierto. En los papeles. Es verdad que en un proyecto mediano o grande habrán analistas (probablemente egresados de económicas) que interpreten el negocio y lo transmitan a los programadores.

Pero yo veo eso no como una característica inherente a los equipos de desarrollo sino como un problema (tal vez generado por la segmentación de las unidades de formación, las universidades) que afecta directamente al mercado de software “de gestión”.

Para un producto que pretenda concentrarse y especializarse en un nicho pequeño (lo que llamamos con cariño “el programita del verdulero”) un equipo de desarrollo compuesto por analistas y programadores es extremada e innecesariamente caro.

En general es un nicho cubierto por uno o dos profesionales que se ocupan de todo, incluso del management de su propio emprendimiento. Si son egresados de alguna de las carreras mencionadas deben superar un duro aprendizaje acerca de “la otra mitad” del negocio, para la que la carrera no los ha preparado.

Recordemos que en conjunto los sistemas de gestión representan la gran mayoría de sistemas existentes, los más cambiantes y dinámicos (tanto como los negocios que soportan), y por ello los que requieren más mano de obra en desarrollo y mantenimiento. Finalmente es donde van a trabajar la mayoría de los programadores, analistas, líderes de proyecto o profesionales independientes con cualquier orientación.

Pero lo que la universidad está produciendo es una mano de obra sobre calificada técnicamente (son los que o se aburren en el trabajo o resuelven los problemas más simples con los algoritmos más inútilmente complejos y eficientes, o no entienden los requerimientos) o en conocimiento del negocio (que producen ese software que resuelve exactamente lo que el usuario necesita pero que por dentro es un desastre y que finalmente se vuelve imposible de mantener o modificar).

Lo que sucede finalmente es que prima la realidad, la necesidad del mercado, y los profesionales se ven obligados a complementar su carrera con experiencia y cursos. En este contexto devalúa el título obtenido. Antes de llegar a ese punto (del que creo que hoy por hoy estamos lejos, pero acercándonos progresivamente) la UBA debería orientar alguna de esas carreras hacia un contenido más balanceado. Una carrera de la cual egrese un profesional que pueda programar algoritmos simples (validaciones, búsquedas, interacción con bases datos, cálculos, reportes) y que conozca el funcionamiento administrativo de las organizaciones (circuitos administrativos, documentos, conceptos contables básicos). Creo que la Licenciatura en Sistemas de Información de las Organizaciones es la que más se acerca, más que nada por el contexto que brinda la Fc. de Cs. Económicas, su proximidad con la carrera de Administración de Empresas y la de Contador.

lunes, 30 de marzo de 2009

Renovación y primeras impresiones de Windows 7

Los asiduos habrán notado una brusca caída del ritmo de publicación en estas últimas dos semanas. El trabajo tuvo algo que ver (no mucho). El inicio de clases, con las corridas y preparativos de última hora pesó un poco más. Pero la razón principal ha sido el fallecimiento de mi computadora de escritorio (una Pentium 4 HT 3.2Ghz).

Es posible que haya muerto de envidia. Su deceso se produjo a las pocas semanas de la compra de una Acer Aspire One (apenas una netbook, pero ya la superaba en performance). A través de este post le rindo un sentido homenaje…

Pero la vida sigue. No soy de jugar con el hardware. Cada vez que una máquina dice “basta” hago el esfuerzo y compro el equipo más potente que puedo para olvidarme del tema por un par de años, durante los que no me preocupo en lo más mínimo por su mantenimiento hasta que casca nuevamente.

Es ésa y no otra la razón de mi elección por un Intel Core 2 Quad Q8200, sobre un motherboard Intel DG31PR con 4Gb de RAM y una placa de video “decente” (no soy un fanático de los juegos), una GeForce 9400 GT.

Lo anterior solamente viene a cuento de poner en contexto lo que realmente me interesa, que no es el hardware sino el software. Hace un tiempo que venía con ganas de probar la beta del Windows 7, así que aproveché la obligada migración para distribuir un poco más racionalmente mis datos (después de un par de años programas, documentos, fotos, videos y desarrollos e instalaciones a medias convirtieron mis discos en una masa compacta, indivisible y desordenada de archivos) e instalarlo en una partición propia.

Preconceptos

La verdad es que si bien la muy respetable opinión (y entusiasmo) de uno de mis compañeros de trabajo cultivó mi curiosidad, era escéptico respecto de la nueva interfaz.

He visto el Windows Vista de lejos pero en la oficina sigo con el XP (que es, en mi opinión -y creo que en la de la mayoría de los usuarios-, el mejor sistema operativo de Microsoft al momento). Esperaba entonces más o menos lo mismo de siempre: muchos cambios estéticos, algunos realmente molestos, la mayoría simplemente inútiles o intrascendentes, y las opciones y funcionalidades de siempre redistribuidas de modo que se maximiza la frustración en las primeras semanas de uso, hasta el momento en el que uno se rinde y somete a los designios de la nueva UI.

Las críticas al Vista, y mi percepción de que el 7 seguiría a grandes rasgos la misma línea no ayudaban mucho. Escéptico por naturaleza, descreía del buzz positivo alrededor de la nueva versión. En resumen, esperaba el chiste de siempre: uno se pasa la primera media hora jugando y los dos o tres primeros días tratando de dejar todo como estaba.

Instalación

Primero hacer un poco de espacio: achiqué la partición de un disco de 300Gb (nota mental: es bueno tener por lo menos dos particiones –datos y sistema operativo-) con el Partition Magic y creé una nueva de 20Gb. Un par de errores y reintentos después los datos contenidos en aquel disco estaban perdidos. Empezamos bien.

Ya molesto por el trabajo de recuperación que se avecinaba inicié con el disco de instalación del build 7057 de Windows 7.

Primera sorpresa: Ok, empezaba con una partición limpia, pero eso no resta méritos. Siguiente-siguiente-siguiente, escasos 20 minutos y ya está. No lloró por drivers, ni pidió actualizaciones, no aparecieron las típicas e inútiles preguntas que interrumpen la instalación cada 5 minutos (obligándome a aburrirme cerca de la máquina), ni siquiera se equivocó con la distribución de teclado.

Me pasé el resto del día recuperando y reorganizando los archivos perdidos en el movimiento de particiones, para finalmente reformatear todo el espacio libre. Trabajo aburrido si los hay, pero tengo que reconocer que la vida es más fácil teniendo las cosas ordenadas.

Primeras impresiones

Sorpresa. Es lindo. Bueno, eso era esperable. Pero más que lindo… es casi… sobrio. No molesta. No pregunta. No aparecen mensajes extraños ni anuncios catastróficos compitiendo por mi atención para que baje, actualice o descubra.

barraWindows7Lo primero que llama la atención es la barra de tareas, con el famoso preview que aparece al pasar el cursor por encima del ícono del programa abierto.

Pero es más que un “chiche”. Moviendo el cursor sobre el preview la ventana emerge al frente mientras las demás se vuelven transparentes, desde allí mismo podemos cerrarla o minimizarla, o volver a la ventana anterior con sólo desplazar el mouse fuera del preview. Se puede agregar o quitar el acceso directo a ese programa en la barra de tareas desde allí mismo, por lo que ya no hay que “personalizarla”, uno lo va haciendo y deshaciendo sobre la marcha.

searchBoxWindows7La otra característica que me impresionó desde el primer momento es el cuadro de búsqueda en lo que antes era el “menú de inicio”. Mantiene el foco siempre que esté abierto el menú y va mostrando los programas y opciones de configuración que concuerdan con lo que vamos tipiando. Creo que puede extenderse para buscar en internet desde allí mismo, pero todavía no lo he probado.

Ese primer día me la pasé explorando y tocando opciones… y dejé todo como estaba. No, no dejé todo igual al XP, dejé todo igual a la configuración por defecto.

La convivencia

Luego reinstalé el XP en otra partición (hay que conservarlo, no olvidar que esto es una beta), y obviamente eso rompió la instalación del 7. Reparé la instalación del 7 desde el CD (identificó el problema –XP instalado después del 7 o Vista embarulla la configuración del multiboot- y lo reparó puntualmente, sin reinstalar) y –obviamente- rompió el XP (bueno, algunas cosas no cambian nunca). Indagando un poco me enteré de que el viejo y sencillo boot.ini fue reemplazado por el retorcido y complicado BCDEdit, que superó en largo mi paciencia para estos temas, con lo cual decidí simplemente borrar todo, instalar primero el XP en una partición, luego el 7 en otra y a otra cosa mariposa (¿ven para qué es bueno tener datos y archivos propios por separado? Yo aprendí de la manera difícil). Pero más allá de esos primeros roces los dos sistemas operativos conviven y comparten el resto de las particiones sin problemas.

Un par de días después

Me rindo, tengo que reconocerlo: Windows 7 es muy, pero muy bueno. Me molesta trabajar con XP, simplemente me molesta. Las nuevas características (sobre todo las dos mencionadas arriba) son tan naturales que es tan fácil acostumbrarse a ellas como difícil resignarlas luego.

Es obvio que Microsoft ha escuchado mucho a sus usuarios y se ha adaptado más a ellos que en otras versiones, abandonando esa actitud de –me parece- imposición de visiones en la forma de interacción con el sistema.

El rendimiento es impecable, aunque es obvio que si no lo fuera en esta máquina ya sería el colmo. Me han comentado que se degrada elegantemente en equipos con menos recursos, pero no lo he probado personalmente.

Han cascado varios programas (por mérito propio), y por supuesto que programando y probando he metido un par de bucles infinitos, ejecutado algún que otro código malicioso, y llevado la máquina casi al límite (con un par de máquinas virtuales haciendo de servidores de base de datos y de páginas web al mismo tiempo) y el sistema operativo ha respondido siempre sin problemas. Dudo que alguna vez le exija más que eso y estoy seguro de que un usuario medio tampoco.

Conclusión

De que Microsoft le ha vuelto a robar ideas se ha vuelto a inspirar en Apple, a Ubuntu y demás no caben dudas. De que nos vuelven a usar como beta testers gratuitos han escuchado a los usuarios tampoco. También es verdad que para mí, por primera vez desde aquel traumático primer pasaje del NT 3.11 al 95 (¡¿dónde están mis grupos?! ¡¿Qué es esto del escritorio?!) la transición es suave, relajada, para nada traumática, y, en definitiva, muy positiva.

Windows 7, en beta y todo, ya es mi sistema operativo por defecto desde hace una semana completa, en la que me he dedicado más a trabajar que a jugar (aunque he vuelto a jugar bastante, ahora que puedo) y tengo que reconocer que es más que cómodo. Por primera vez Microsoft ha logrado que su interfaz llegue velozmente al objetivo: volverse invisible al usuario.

Ahora no hay excusas para volver al ritmo habitual. Nos leemos.

sábado, 31 de enero de 2009

Una anécdota sobre la percepción de seguridad.

La entrada Experto que acabo de sacar y el comentario que hizo en ella Senior Manager remarcando el término “percepción” me hicieron acordar de…

una anécdota: tenía… 19 o 20 años y trabajaba de “Ayudante de Sistemas de Control Operativo”. Básicamente era el que “sabía de computadoras” a la hora de elaborar informes ad-hoc y programar pequeños procesos de depuración o lo que hiciera falta.

Resulta que el gerente del que dependía ascendió en la estructura, y dedicó uno de sus últimos días a borrar sus cosas personales de la computadora y la red. En un momento me llamó –nos llevábamos bien, por suerte- y me dijo:

-¿Podrías grabarme los archivos que están en mi carpeta personal de la red –súper personal, súper secreta y privadísima del gerente- a un disco?

Se refería a un ZIP, o a algo igualmente obsoleto ahora, supongo.

-Ok –dije, di media vuelta y me fui sin más preguntas ni comentarios a hacer mi tarea... ¿Se entiende?

Y supongo que ésa fue la última vez que el tipo guardó un archivo con información privada o delicada en una red corporativa.

Saquen sus conclusiones. Yo usaría Google Apps.

lunes, 19 de enero de 2009

¿Por qué renuncian los que renuncian a Google?

Parecer ser que se ha colado a TechCrunch (Why Google Employees Quit) una serie de posts de un foro abierto por Google en 2008 para preguntar a ex-empleados por qué renunciaron a la compañía. Habrá que ver si no es un fake, pero si TechCrunch lo da por bueno ya es bastante…

Leyendo salteado (la verdad que después de un par se hace un poco repetitivo y hay como 330 comentarios) confirmo el delirante proceso de ingreso a Google, no sólo por las preguntas sino por su duración (más de 5 meses).

También confirmo parte de lo que imaginaba en A great place to work: si bien parece ser que todo lo que brilla en Google es oro (se confirma la buena comida, el buen ambiente -en general-, los beneficios y todo eso), ese oro no es lo esencial al momento de valorar positivamente un ambiente laboral.

Odio decir esto porque por orgulloso me cuesta recular (como resumía la frase de Larry Wall que referenciaba en este post), pero termino apreciando a la pequeña pyme amarreta, desagradecida, descontrolada, delirante a veces, un poco chanta siempre… pero en la cual, finalmente, uno termina sintiendo que gana en experiencia de la “vida real” y aporta algo sustancial, ya sea o no reconocido por los demás.

En definitiva, ya sea en Google o en NN S.A., lo importante es levantarse con ganas todos los días pero sin olvidarse de que no es un barco. No hay que tener reparos en irse de ningún lado.

Vía Google Blogoscoped.

viernes, 16 de enero de 2009

Limitaciones de los modelos ágiles (y de todos los modelos).

Navegápolis nos refiere un muy interesante artículo de Bruno Collet: Limitations of Agile Software Development.

En él se describen y analizan algunas limitaciones percibidas en los modelos ágiles de desarrollo:

  1. Equipo de estrellas.
  2. Encaje con la cultura organizacional.
  3. Tamaño del equipo.
  4. Ubicación física del equipo.
  5. No hay apoyo de procesos.

Obviamente está en inglés, largo pero de fácil lectura. Vale la pena el esfuerzo.

Mi personalísima opinión –bastante en sintonía con el autor del artículo- es que ninguna metodología en estado puro (“de libro”) es aplicable en la vida real sin ajustes, y que por sobre cualquier otro criterio debe primar el pragmatismo, sin olvidar la precaución (no seguir las modas o novedades), y el gradualismo (las revoluciones son muy emocionantes, pero…)

Es importante recordar que el objetivo del desarrollo es crear software, por lo que la metodología es un medio que debe estar en línea con ese objetivo, no un fin en sí mismo.

La situación actual es siempre un punto de partida. Cada problema tiene origen en alguna debilidad del proceso, que de alguna manera permitió su aparición. Sobre esto escribía en Parches y soluciones:

[…] puede pensarse en un parche y una solución para cada problema […] El parche es la actividad que resuelve la situación puntual, mientras que la solución es un cambio en la metodología de trabajo o en el circuito administrativo dentro del equipo que torna imposible la situación que originó el error.

Siempre se parte de una realidad existente, no importa si es el primer proyecto independiente de dos amigos/socios o un proyecto de mantenimiento en una gran corporación. Durante la marcha (o en algún momento de evaluación) surgen dificultades, cuellos de botella, errores, omisiones o indefiniciones.

Son éstos problemas e ineficiencias concretas, nuestros problemas y nuestras ineficiencias las que se deben corregir. Y para ello está disponible no sólo la experiencia volcada en las metodologías ágiles sino en cualquier otra, incluso de diferentes ámbitos o industrias.

En resumen:

  • pragmatismo. trabajar sobre lo concreto: problemas concretos, soluciones concretas.
  • experiencia: referirse siempre a la experiencia. A la nuestra o a la ajena, pero no reinventar la rueda. Puede que un producto sea original, novedoso y único, pero créanme: los problemas en el proceso que lleva al desarrollo de ese producto no lo son. Antes de ponerse creativos es mejor hacer una búsqueda en google.

sábado, 10 de enero de 2009

Google Chrome avanza.

Estaba leyendo otro artículo más sobre el constante y acelerado retroceso del IE y se me ocurrió chequear nuevamente en las visitas a este blog.

Por supuesto es un universo muy pequeño y muy sesgado. De todas maneras recuerdo que un par de semanas después del lanzamiento de Chrome éste se ubicaba en torno al 3%.

Ahí va:

navegadores

Un brutal 12% entre el 10 de diciembre y el 9 de enero. Tendría que hacer un análisis más profundo, pero a ojo de buen cubero creo que le ha mordido más a Firefox que al IE. ¿Es igual en sus blogs?

miércoles, 31 de diciembre de 2008

12 fuentes de competitividad en el siglo XXI

competitividad Saltando por allí caí en este post de Consultoría artesana en red en donde Julen (que tiene una buena experiencia sobre sus espaldas) resume en 12 las fuentes de competitividad de las organizaciones.

Hay muchas de estas listas, la mayoría llenas de frases vacías. Así que se las recomiendo especialmente para que no se les pierda en este mar de información en el que navegamos todos los días (estoy hecho un poeta hoy).

Los puntos son:

  • Sentirse más que una empresa.
  • Coger olas.
  • Dejar hacer.
  • Diseñar paracaídas.
  • Eliminar perfiles de puestos de trabajo (¡Ojo con esta, que no quiere decir despedir gente!).
  • Gestionar en Internet.
  • Conseguir diversidad interna.
  • Clientes y usuarios son parte de la organización.
  • Abandonar rápido.
  • Olvidar productos y servicios, una empresa trabaja con estilos de vida.
  • Trabajar en abierto (casi) todo.
  • No crecer, sino desarrollarse.

Todos estos puntos están desarrollados y comentados en la entrada original.

martes, 30 de diciembre de 2008

WTF: Plataforma pro-salvación de VB (!?)

Vengo de leer Plataforma pro-salvación de Visual Basic .NET (SVB.Net). No quiero pelearme con nadie, pero... ¿realmente es para tanto?

Para aquellos a los que les de fiaca seguir el link, vamos a lo esencial, y cito:

[...] Para el que todavía no esté al tanto de la historia, durante la segunda semana de diciembre ha tenido lugar en Dallas el encuentro de desarrolladores DevConn4, en el que Matt Gretz, destacado miembro del equipo de VB.NET, hacía público el Roadmap que Microsoft tiene previsto para este producto, que no trae buenas noticias para la gran comunidad de desarrolladores en Visual Basic, y que provocó un revuelo impresionante tanto en la sala del evento como en la blogosfera y medios especializados.

Resumidamente, el Roadmap prevé la progresiva desaparición de Visual Basic, mediante un plan de migración que facilitará los desarrolladores pasar a C# en un plazo de tres años. [...]

En principio pongamos los pies en la tierra. Todo esto no implica que para 2012 VB muera abruptamente y todo aquel que desarrolle en ese lenguaje sea etiquetado de obsoleto y puesto de patitas en la calle. Valga como ejemplo la cantidad de programadores en tecnologías "viejas" (¡de hace más de veinte años!) que todavía son requeridos, y muy bien pagos por cierto. Así que si la discusión es por lo laboral, no le veo mucho sentido.

Es un problema el tema de las certificaciones, supongo. Pero para cualquiera que tenga un mínimo de conocimientos de programación, una certificación en VB es casi equivalente a una en C#... aunque reconozco que no sé hasta qué punto se "ablandan" los criterios en cuanto a certificaciones en las empresas que las requieren. Aquí los defensores pueden tener un punto, aunque de hecho ni es mencionado como problema.

Si la discusión es más "filosófica" (funcional, digamos), sigo sin entenderla. Tenemos dos lenguajes que, hoy en día, son prácticamente equivalentes. Me arriesgaría a decir, incluso, que si molestan sus pequeñas diferencias es porque uno a esta altura pretende escribir exactamente la misma serie de líneas de código con distintas palabras o símbolos en cada uno de ellos.

Si hablamos de gustos bueno, es otra cosa. Al que le gusta más VB le gusta más y no hay argumento en contra ni a favor de ello. Sobre gustos no hay nada escrito, como quien dice. Yo programaba en VB y luego pasé (forzosamente, no fue una elección) a C# y me gustó más, pero podría no haber sido así.

Pero a lo que voy es... es tan sólo un lenguaje. Si uno sabe programar, sabe programar y punto. Obviamente que la adaptación a un lenguaje específico cuesta, pero ¿tanto realmente?

Que se entienda, lo que me sorprende es esta "lucha por la supervivencia" no de VB en particular sino de un lenguaje de programación, que podría ser cualquiera. Me sorprende que alguien esté tan apegado a un lenguaje como para montar tremendo esfuerzo. Yo no lo haría ni por VB, ni por C# ni por ningún otro.

¿A uds. que les parece?

domingo, 9 de noviembre de 2008

Las personas: el activo de las empresas... no.

Un poco a cuento de las cuestiones laborales sobre las que venía reflexionando, dos perlitas:

1) Yoriento referencia una frase vista en el blog de Escolar, atribuída a "Eusebi Cima, vicepresidente de Fomento del Trabajo (la patronal catalana) y presidente de la patronal Fepime, sobre las ayudas de 1.500 euros para los empresarios que contraten a parados con cargas familares":

"Desgraciadamente, lo que necesitamos son ayudas para despedir a la gente. Hay un ajuste de mercado, una crisis muy grave, se está generando desocupación y no puestos de trabajo. Ahora no es el momento de crear este tipo de ayudas."

2) Un extracto (muy iluminado, a mi entender) del blog de Javier Llinares (no tiene relación directa con el punto 1):

Yo no estoy de acuerdo en que las personas sean el mejor activo que tienen las empresas, ni siquiera estoy de acuerdo en que las personas sean un activo de las empresas, ya que si fuesen algo que poner en el balance, en lugar de en la cuenta de resultados, creo que lo que serían es un renting.

Las personas son un activo para ellas mismas, nunca para las empresas, ya que para que algo sea considerado un activo, tiene que existir cierto nivel de posesión, y naturalmente las personas solo se pertenecen a ellas mismas.

El resaltado es mío. Les recomiendo el artículo completo.

sábado, 8 de noviembre de 2008

Qué significa NINJA en "Crisis NINJA".

Voy a deschavar (con alguna vergüenza) mi desconexión absoluta de la actualidad en estos días (que no de la realidad, que es bien diferente) y de paso hacer un favor a quienes no se atrevían a preguntar.

Acabo de leer en el blog de Javier Llinares Salas, por primera vez, el significado de NINJA, término que ha estado dando muchas vueltas estos meses:

NINJA = No income, no job, no assets, es decir que un ninja es una persona que no tiene ingresos, no tiene trabajo y no tiene propiedades.

Un rayo de luz al interior de mi zócalo...