Pentacour

Un reciente cabreo de un programador me ha animado a dejar por escrito lo que pienso sobre la cultura tan en boga del “todo gratis”. Estamos viendo multitud de webs exitosas gratuitas sin un plan de negocio, google que constantemente nos da servicios que hace unos años sería inimaginable que fuesen gratuitos, y quien se queda ahí, no se plantea que detrás de todo esto, como mínimo hay personas con la manía de tener que comer todos los días. Me “hacen gracia” los que se jactan de sus AddBlocks y me gustaría preguntarles que de dónde creen que sale el dinero para mantener esas webs. Vale que a veces hay publicidad incordiante e intrusiva, pero unos anuncios bien puestos, a mi no me molestan y permiten que quien hay detrás de la web tenga un pequeños beneficio.

Otra cosa es que yo haga software libre o aplicaciones gratuitas en mis ratos libres. Vale, perfecto, pero debo ser consciente que no podré vivir de ello. Y claro, no puedo tampoco montar un negocio pensando en las donaciones de la gente. El programador del primer enlace se ha dado de morros con la realidad. Entiendo su postura: 40000 descargas de las cuales, alguno lo estará usando, e incluso alguno estará vendiendo programas con ayuda de su herramienta. Pero no le donan nada. ¿Qué se creía? Todo gratis.

El software libre está haciendo mucho bien a la tecnología, pero creo que es algo más complicado que el criticar a Microsoft o ponerle motes graciosos. No podría permitirme estar 4 meses programando algo sin cobrar, liberarlo y después ¿qué? ¿De dónde saco el dinero para comer? Sí, hay casos que con servicios, o como Wordpress dando hosting… vale. ¿Y si lo hago tan bueno que es tan intuitivo que no hace falta dar servicio? ¿Qué gano con ese programa a parte de la satisfacción personal? Que ya digo que puedo hacer programas gratuitos en mis ratos libres, pero eso mismo, por satisfacción personal. Pero ¿podría vivir de ello? No creo que sea posible en todos los casos. Podría hacerlo para un cliente y luego liberarlo. ¿Le hará gracia al cliente haber pagado el programa y que luego la competencia lo use sin coste alguno?

Por supuesto estoy a favor del software libre. Creo que es el caminio. Pero veo muchas voces acaloradas defendiéndolo dando argumentos muy flojos. Sobre todo que sea gratuito, porque si es libre y puedo compilarlo, podré usarlo gratuitamente. Pero ¿y si el programador quería vivir de ello? ¿O debe el programador hacer software privativo en su trabajo, y en los ratos libres hacer software libre? Qué cosas más contradictoria, ¿no? Un profesor de informática tiene su trabajo y puede hacer programas libres en sus ratos. Pero a esos a quienes forma, ¿cómo ganarán su dinero al salir de la universidad?

Me gusta la idea de lo libre, pero tengo muchas preguntas sin respuesta. Por eso lo defiendo, pero sin gritar, porque según qué argumentos, ahora mismo no podría rebatir.

Estoy cansado de acostumbrado a escuchar  la frase “por mail no, mejor cuando lo sepa te llamo un momento y te lo explico, que es mejor”. Pues permíteme dudarlo. Creo que hay clientes/personas que infravaloran esta herramienta. Tiene una utilidad mucho más poderosa que el reenviar power points con las mismas tonterías una y otra vez.

Por orden de eficacia, en la comunicación con el cliente yo pondría: reunión cara a cara, correo electrónico y conversación telefónica. Siempre hay casos que rompan estas prioridades, pero de manera general, para resolver una duda o plantear una cuestión, para mi son éstas. En una llamada telefónica no concertada, no sabemos qué está haciendo la otra persona: si en ese momento está en el coche, reunido, en el lavabo, concentrado en otro tema… No queda nada por escrito y además, se puede dar la situación de que el interlocutor no haya cambiado correctamente de contexto, y seguramente diga “vale vale, aunque luego lo pienso mejor”, con lo que probablemente tenga que haber una segunda conversación.

Hay que partir de que escribir un correo electrónico planteando una duda, una especificación, al programador, al cliente, no es como hablar (si se quiere hacer bien, claro). Nos obliga a pensar detenidamente lo que queremos plantear y describirlo lo más claramente posible. Esto es un buen ejercicio porque al verlo plasmado en pantalla y releerlo podemos notar si no lo estamos expresando bien, si hay vacíos en el planteamiento, o en el mejor de los casos, encontrar la solución directamente al haber pensado más de un minuto en ello.

Normalmente, mis mejores clientes, con un correo planteando un duda basta para obtener respuesta y solucionarla. Cuando algún otro me dice la frase con la que empiezo el post, malo. O llamadas por cualquier cosa, que muestra que ni han leído el manual ni han perdido treinta segundos en pensar, o llamadas para explicarme una especificación que querrían, que óbviamente, si no han querido escribirla, es que no la tienen bien pensada, por lo que se explican mal por teléfono, se les plantean dudas, se lo piensan, vuelven a llamar, etc (pérdida de tiempo).

Intento dar incentivos a mis clientes si usan el correo electrónico, diciéndoles que les podré responder en pocas horas y evitando hacer malabarismos para contestar por teléfono si estoy ocupado en otra tarea.

¿Cuál es vuestro punto de vista?

En un proyecto surgió que el cliente estaba dispuesto a ir probando la aplicación mientras se iba desarrollando. En principio me pareció genial, porque se trataba de un programa complejo con muchas funcionalidades y sería una manera de ir validando el desarrollo. Por otro lado, un cliente suele ser un buen localizador de bugs.

La conclusión a la que he llegado es que no se puede aplicar a cualquier programa ni sobretodo, a cualquier cliente. Los que no desarrollan software, pueden no entender los pasos que se están dando al realizar la aplicación y llegar a entorpecernos involuntariamente.

Estos son los problemas con los que me he encontrado:

- El cliente no entiende que cuando hay algoritmos complejos, lo importante primero es validarlos y al final ya se comprobará que el usuario final entre los datos correctamente, se cambiará el aspecto de la interfaz, etc. Es decir, él debe vigilar que los datos que entra tengan sentido. Pueden empezar a llegar correos y llamadas sobre problemas en la interfaz o en que “me deja entrar un fecha incorrecta”.

- El cliente ve el armazón de la aplicación y se aventura a probar funcionalidades no terminadas todavía en vez de la pactada: correos y llamadas diciendo que la otra parte no funciona o que si ya se ha tenido en cuenta tal o tal aspecto cuando no es el momento de tratarlo.

- El cliente no entiende bien su rol, cree que es parte del equipo de desarrollo y puede llegar a enviar mails y llamadas a cualquier hora por cada fallo que crea haber encontrado, en vez de una lista por correo electrónico con todos los problemas tal y como se pactó.

- El cliente ve una aplicación que parece terminada y ya desea enseñarla a sus clientes, superiores, etc. Pero te pide que le acabes tal aspecto de la interfaz o tal funcionalidad (que todavía no toca) porque causará mejor impresión. Esto supone una gran pérdida de tiempo y en ocasiones trabajar dos veces.

Por lo tanto, aunque no sea culpa de él, ya que quizás le hemos asignado un papel que no le correspondía, nos hace perder mucho tiempo respondiendo llamadas, correos, dando explicaciones y desactivando opciones del menú que no debería probar.

Respondiendo a la pregunta del título, diría que vale, pero si conocemos bien al cliente y estamos seguros de que no entorpecerá el desarrollo de la aplicación.

Actualización: A raíz de un pequeño debate en plurk, aclaro que en ningún caso estos “tests del cliente” vienen a sustituir a los tests programados por el equipo de desarrollo.

Como primer post después de la miniparada vacacional quería algo fuerte y osado. ¿Y qué puede haber más osado que decir que no te acaba de gustar un producto de Google?

Pues eso, he probado el nuevo navegador Chrome, con mucho cariño, y aunque al principio me entró por los ojos y tiene algunas soluciones muy buenas, no me acaba de hacer el peso. Ni mucho menos lo he probado a fondo ni he hecho benchmarkings ni he rebuscado todos los entresijos del navegador. He hecho lo que seguramente hará el 90% del público: navegar con él y ver si va rápido, ágil y no se cuelga. En este mundo actual con multitud de ofertas, hay productos a los que se les dan pocos segundos para que gusten. Por ser Google, éste tendrá más tiempo.  Pero tiene duros competidores y seguro que habrá usuarios a los que si se le cuelga en los primeros 5 minutos no volverán a arrancarlo.

Lo primero que hice fue abrir un foro y la página de plurk. Pues creo que tardó menos de 5 minutos en colgarse. Abrí bloglines, seguí algunos enlaces y se quedó congelado. Esperé un tiempo prudencial (30 segundos que ya son muuuchos) y nada. Así que lo primero que pensé es que lo de Beta está muy justificado. Lo que me extraña es que al ser multiproceso y ver que abre tantos como pestañas, una pestaña me cuelgue todo el navegador. Precisamente eso era lo que pensé que sería un punto a favor respecto a Firefox, que se me suele colgar con algunos vídeos de youtube.

Por otro lado, lo del Javascript compilado no lo acababa de ver. Me parecía más como una opción para márqueting que una solución a un problema real. Las máquinas de potencia mediana no deberían tener problema para ejecutar el javascript de las webs, ya que tampoco tienen que solucionar ecuaciones diferenciales. Lógicamente, al compilarlo irá mucho más rápido, pero ¿se notará tanto? Bueno, iba a despotricar, cuando he leído en Dirson que es una apuesta de futuro, ya que aplicaciones como google docs o google maps sí que hacen un uso intensivo de Ajax y ganará mucho. De todas maneras, son graciosos los benchmarkings de comparativas de rendimiento de Javascript con otros navegadores, en que Chrome destroza a todos los rivales. Faltaría más; si es compilado. Estaría bien probarlo en máquinas medias bajas y contando el tiempo de compilación. Que quizás sigue rompiendo, pero vería más justificados esos gráficos de barras grandilocuentes. A parte claro, que por las páginas que suelo navegar, así, a ojo de buen cubero, quizás me haya ido unos milisegundos más rápido con Chrome los efectos dependientes de Ajax… De todas maneras, no lo veo mala decisión. Aunque ahora no se note nada, a corto/medio plazo en que migren más aplicaciones del escritorio a la web y haya más Javascript, puede que sí se acabe notando.

Lo que me gusta es que al abrir una página nueva te muestre las que más visitas, los efectos que incorpora al bajarse un archivo o picar aquí y allá, que parece más “inteligente” al adivinar la url que quieres escribir en la barra de direcciones, y que sea multiproceso, que aunque me siga colgando una pestaña todo el navegador, seguramente se notará la diferente gestión de memoria al llevar un rato navegando.

Por otro lado, me da la sensación que Google con un navegador, puede bajar del mundo de los dioses. En el primer día ya le han encontrado un bug y casi seguro que caerán más, es normal. Pero veremos que Google también tiene bugs.

De todas maneras, aunque los devotos de la Hermandad de San Google pasarán a utilizar con los ojos cerrados Chrome, yo seguiré probando las nuevas versiones que vengan, pero de momento, sigo con Firefox.